Modello di Connessione Sociale
Stato: Proposta approvata — implementazione da pianificare Data proposta: Marzo 2026 Autore: Elia (founder)
Sintesi
Flow abbandona il modello follower/following asimmetrico a favore di un grafo amici-only (connessioni reciproche), con livelli di profondità della connessione calcolati automaticamente dagli eventi frequentati insieme.
Il Problema del Follow Asimmetrico
Le piattaforme mainstream (Instagram, TikTok, Twitter) usano il follow asimmetrico perché il loro prodotto è la distribuzione di contenuti: seguire una persona significa ricevere i suoi post nel feed, indipendentemente dalla conoscenza reale.
Flow non è una piattaforma di contenuti — è una piattaforma di eventi IRL condivisi. Il follow asimmetrico importerebbe sul prodotto una serie di dinamiche che contraddicono la sua identità:
| Problema | Effetto su Flow |
|---|---|
| Asimmetria di status (follower vs following) | Crea una gerarchia sociale artificiale non coerente con “uscire insieme” |
| Metrica gonfiabile (follower count) | Incentiva comportamenti da “influencer” estranei al contesto notturno/IRL |
| Complessità UX | Due liste distinte (chi segui, chi ti segue) senza valore reale per l’utente |
| Privacy implicita ridotta | Chiunque può seguirti e vedere la tua attività senza consenso reciproco |
La Proposta: Amici Only
La connessione su Flow è sempre bidirezionale e consenziente:
- Utente A manda richiesta di amicizia a Utente B
- Utente B accetta
- Entrambi diventano amici — possono vedere la reciproca attività e invitarsi agli eventi
Non esiste il concetto di “seguire” qualcuno. Ogni connessione è una relazione reale, come nella vita offline.
Eccezione: Organizzatori e Locali Verificati
I profili verificati (locali, organizzatori di eventi, PR ufficiali con badge staff) possono avere un meccanismo di “follow” separato — sono entità di contenuto, non persone fisiche. Questo è coerente con il modello “amici tra persone, follow per organizzatori”, simile a Spotify (seguire un artista ≠ amicizia).
Questo è fuori scope per ora — da valutare nella fase B2B.
Livelli di Connessione (Connection Depth)
La proposta più interessante è che la profondità di un’amicizia venga calcolata automaticamente dai dati reali, senza che l’utente faccia nulla.
Tier proposti
| Tier | Nome | Criterio (proposta) |
|---|---|---|
| 0 | Conoscente | Richiesta accettata, nessun evento in comune |
| 1 | Amico | 1–2 eventi frequentati insieme |
| 2 | Compagno di uscite | 3–5 eventi frequentati insieme |
| 3 | Crew | 6+ eventi insieme, o nella stessa Crew attiva |
Il tier è visualizzato in modo sottile nel profilo dell’amico (es. piccola icona o label sotto il nome) — non è un numero da mostrare in grande.
Perché automatico e non manuale
- Nessuna pressione sociale: non devi “etichettare” qualcuno come best friend — il sistema lo inferisce dai fatti
- Coerente con la filosofia Flow: il legame è costruito dalle esperienze condivise, non da un click
- Dati utili per raccomandazioni: sapere che sei “Crew tier” con un gruppo permette al sistema di suggerire eventi a quel gruppo
Note implementative
Il calcolo potrebbe avvenire:
- Batch: job notturno che aggiorna i tier per tutti gli utenti
- Event-driven: dopo ogni check-in/RSVP confermato, ricalcolo per le coppie coinvolte
La tabella friendships in Supabase andrebbe estesa con un campo connection_depth (int, 0–3) aggiornato dal job.
Impatto sull’Implementazione Attuale
File da modificare
| File | Cambiamento |
|---|---|
lib/shared/models/user_model.dart | Rimuovere followersCount, followingCount; aggiungere eventualmente connectionDepth in FriendUser |
lib/features/profile/screens/profile_screen.dart | Stats row: da 3 pillole (Amici / Follower / Seguiti) a 1 pillola Amici (o 2 con Crew) |
lib/features/profile/screens/public_profile_screen.dart | Pulsante “Segui” → “Aggiungi amico” / “In attesa” / “Amico ✓“ |
lib/features/social/notifiers/social_notifier.dart | Rimuovere follow/unfollow actions; potenziare sendFriendRequest |
Route /profile/social-list/followers | Da eliminare o unificare nella lista amici |
Route /profile/social-list/following | Da eliminare o unificare nella lista amici |
Supabase schema profiles | Colonne followers_count, following_count diventano non usate lato UI (rimozione con migration separata) |
Supabase schema friendships | Aggiungere colonna connection_depth INT DEFAULT 0 |
Cosa NON cambia subito
- Il backend Supabase può mantenere le colonne follower/following per ora — vengono semplicemente ignorate dall’UI (zero breaking changes sulle API)
- La logica di amicizia (
sendFriendRequest,acceptFriendRequest) esiste già — è la base su cui costruire
Open Questions
- Visibilità dell’attività: tra amici tier 0 (conoscente) si vede l’attività su “Cosa fanno gli amici”? O solo da tier 1 in su?
- Connessione depth nel profilo pubblico: il visitatore vede il suo tier con quella persona, o è privato?
- Notifica di upgrade tier: vale la pena notificare “Sei diventato Crew con Marco!” dopo il 6° evento? Potrebbe essere un momento di engagement positivo.
- Soglie dei tier: i numeri proposti (1-2 eventi, 3-5, 6+) sono arbitrari — andrebbero calibrati sui dati reali una volta che ci sono utenti.
- Decay: se due amici non escono più insieme da 6 mesi, il tier scende? O rimane storico?
Riferimenti
- Discussione founder →
developbranch, sessione Marzo 2026 - Schermata profilo attuale:
lib/features/profile/screens/profile_screen.dart - Modello dati amici:
lib/shared/models/user_model.dart(classeUser, campofriendsCount)