Ma i dati devono proprio stare nel cloud?

Ci sono configurazioni intermedie, nel senso che magari un client chiama il server SIP su IP, il server SIP va sulla rete telefonica e chiama l'altro client usando una normale telefonata (1). Oppure il caso in cui  entrambi usano il server SIP per la telefonata.

La seconda fase, detta SDP, Session Definition Protocol, consiste nel fare in modo che i due client si accordino su COSA scambiare. Normalmente su SIP si scambia una normale chiamata voce, ma per come e' definito SDP, i client potrebbero scambiarsi mail, immagini, indirizzi web, pagine html, documenti word, qualsiasi cosa abbia un mime type.

Allora, se immaginiamo un social network che si comporti come SIP, e divida la parte di iniziazione della sessione da quella di definizione dei dati scambiati, potremmo avere effettivamente un social network che tenga i dati dell'utente a casa.

Uno cellulare smart ha oggi la possibilita' di ospitare diversi GB di storage. Idem il vostro computer di casa, che ormai avra' terabyte di spazio su disco. Anche una semplice console per giochi ha spazio a iosa, ormai.

La domanda e': possiamo immaginare un social network ove l'interazione tra gli utenti sia definita dal client? COme ho detto, assolutamente si. Un simile social network si comporterebbe circa in questo modo:

• L' utente A si logga nel social network. Tutti i suoi dati sono sul PC/SmartPhone/Quelchele client. Uno o piu' di uno.
• L' utente B si logga nel social network. Tutti i suoi dati sono sul PC/SmartPhone/Quelchele client. Uno o piu' di uno.
  
• L'utente A (il suo client) vede sulla sua bacheca che l'utente B ha convidiso una risorsa. Diciamo una foto.
• Il client dell' utente A si collega al social network e chiede "come reperisco questa foto?".
• Il server del social network fornisce l'indirizzo IP e l'hash tramite cui reperire la foto.
• Il client dell'utente A contatta il client dell' Utente B e gli chiede la foto.
• Se vuole o se puo' , il client dell'utente B la  fornisce al client dell'utente A.
• L'utente A vede la foto di B nella sua bacheca.

Ora, sicuramente gli esperti di rete staranno inorridendo. E' abbastanza chiaro a quali problemi andrebbe incontro un sistema del genere. In generale:

1. Se l'utente B ha piu' di un dispositivo (diciamo un PC, una console, e uno smartphone), su quale dei client deve essere la foto? La risposta e': i client devono tenersi continuamente allineati tra loro. Un simile sistema quindi deve prevedere un meccanismo di allineamento tra i client. In questo modo, si ridistribuisce la capacita' dello storage, si ridistribuisce il consumo di rete (che non e' piu' diretto verso il centro-stella rappresentato dal social network) e si creano copie di backup.
2. Ovviamente questo risente delle latenze di rete. Su questa affermazione qualcuno potrebbe concordare e qualcun altro no. Innanzitutto, questo sistema fa poche chiamate al nodo centrale, e poi se la sbriga tra i client. Se i client sono nella stessa rete/ISP, come capita per esempio agli utenti di Fastweb, o nelle universita', non e' detto che la banda sia poca. I client piu' lenti peraltro sono sincronizzati con una copia (diciamo la copia nel PC di casa) e possono se necessario redirigere li' le richieste.
   
3. Il sistema funziona solo se almeno uno dei vostri client e' online. Ma questo e' proprio il bello: potete disconnettervi  impedendo accesso FISICO ai vostri contenuti. Potete decidere, attraverso un firewall, chi puo' e chi non puo'. Ovviamente, se VOLETE essere sicuri di essere visti, dovete lasciare un client che giri sempre in una rete a banda decente, tipo il computer di casa. Ovviamente tutti gli altri client devono scegliere se essere master o slave, nel qual caso si limitano a sincronizzare i contenuti.
4. Il cloud viene visto anche come sistema di backup. Vero. Ma per questo potete semplicemente avere molti client sincronizzati tra loro. Il vantaggio in compenso e' che avete un completo controllo sull'accesso dei dati, ovvero potete sapere in tempo reale CHI sta accedendo ai vostri contenuti.
   

Non sono certo, senza una apposita fase di test, che i "cons" superino i "pro". Occorrerebbe fare un test. Di fatto , un simile social network, avrebbe requisiti simili a questi:

1. Si comporta come un server di autenticazione. Tutti i client si autenticano li'.
2. Quando un contenuto viene condiviso, si limita a salvare un hash unico nel database, e l'identita' di chi ha sottoposto il contenuto. Condividere un contenuto consiste nel salvare l'hash del proprietario e l'hash del contenuto sul social network. Il contenuto NON si muove dal client.
   
3. Quando ci sono piu'  client, ogni  software client si fa carico di sincronizzarsi tra diversi dispositivi. Il client si fa anche carico di redirigere le chiamate verso il client piu' veloce.
4. Quando il social network, il nodo centrale, riceve la richiesta di un contenuto , si limita a restituire una redirezione al luogo ove si trova il contenuto.
5. Il client che vuole leggere il contenuto deve autenticarsi anche col client che lo deve fornire. Il quale confronta l'hash del richiedente con uno che ottiene dal server, ottiene un nounce, e se e' chi dice di essere, allora lo fornisce.
6. Valgono i filtri di privacy che settate SUL CLIENT, e non quelli che settate sul server centrale.

Fatto cosi', su una rete abbastanza veloce, il nostro social network potrebbe offrire il 100% delle feature di Facebook o G+ , lasciando pero' a VOI il TOTALE controllo del vostro contenuto. Se teoricamente formattaste tutti i sistemi client, solo chi ha salvato il contenuto potra' ancora conservarne una copia, perche' altrimenti non ci sara' piu' modo di ottenere, via social network, il contenuto che avete distrutto.

Ovviamente questo rende difficile condividere oggetti grossi, come il filmati, visto che un simile sistema consuma banda. Si tratterebbe quindi di scrivere un client molto piu' sofisticato del server, che gestisce tutto quanto ho detto sopra, piu' il codec con cui fare le cose, eccetera.

Tuttavia, questo ci fornisce una risposta chiara alla domanda: e' TECNICAMENTE necessario che Facebook e Google salvino tutti i contenuti nel PROPRIO database? La risposta e' NO, non e' tecnicamente necessario: il server stesso potrebbe comportarsi come un tracker di torrent, e quando condividete un contenuto potete semplicemente condividere il torrent relativo, in modo che poi via torrent sia possibile recuperarlo da tutti i vostri client (PC, Smartphone, Game Console, etc )

E' ECONOMICAMENTE necessario che questi dati siano salvati sul server centrale? La risposta e' che temo di si' . Il modello di Facebook  e' tale che senza quei dati, non ha business. La pubblicita' non consiste solo nello sparare la reclame alle persone: consiste nello spararla alle persone giuste: questo significa che per vendersi come un canale pubblicitario EFFICACE, quello che raggiunge VERI clienti, Facebook DEVE analizzare i vostri dati, e per farlo deve per forza possedere il vostro storico.

Un simile Social Network e' possibile, in altre parole, SOLO se non e' "gratuito", ovvero se si paga l'accesso. C'e' da dire che per come l'ho appena pensato, un sistema del genere NON necessita di nulla rispetto all'enorme infrastruttura di F o G+: in fondo e' un misto tra un server per l'autenticazione e un gigantesco tracker torrent che per ogni cosa che condividete crea un torrent e permette a chi accede al torrent di provare a scaricarlo dai vostri computer/smartphone/game console. Non consuma troppa banda perche' in definitiva non necessita di ricevere ogni contenuto, ma solo un file torrent, che poi inserisce nel frame della home page come referenza al contenuto: voi decidete di condividere una immagine, e il vostro client manda un torrent al server. Il quale lo fornisce, ma tanto poi spetta al client in vostro possesso decidere chi scarica l'immagine dai vostri dispositivi e chi no. In questo caso, il consumo di rete si sposta tra i client.

Se considerate che  i tracker torrent hanno gia' meccanismi di autenticazione che permettono solo ad alcuni di scaricare i contenuti , di fatto stiamo riducendo tutto il social network ad una interfaccia web centrale "potenziata" dal fatto di presentare le risorse sotto forma di un relativo torrent a download ristretto, la quale fornisce solo il frame e la struttura del sito, e il client non e' altro che un browser che quando trova un oggetto embedded "di un certo tipo" (magnet link?) lo scarica usando torrent , piu' un client che fa sia web che torrent, e che decide a chi dare i vostri contenuti ed a chi no. Le configurazioni di sicurezza sono sul client. Niente di piu'.

Anche lo storage non vi serve troppo, visto che si, dovete avere  lo spazio per i dati di autenticazione e per i file torrent, ma niente di piu': i contenuti sono tutti sui client.

Il vero problema di un modello simile e' che di per se' la sicurezza si sposta sul lato client, e quindi dovrete stare molto attenti ai meccanismi di autenticazione client-server e client-client,  e nessuno vieta ad un client di ricondividere il contenuto fuori dal vostro controllo: vi faccio presente pero' che questo avviene ANCHE OGGI, voi non sapete cosa fara' chi legge la vostra pagina delle vostre foto, quindi non e' un problema che risolverete centralizzando tutto.

Certo, non e' una passeggiata mettere in piedi un sistema del genere, ma non necessita dei numeri di Facebook per stare in piedi, e questo e' il punto: vista la quantita' minore di risorse che richiede al nodo centrale,   anche a due euro/anno per utente, oltre ~1M utenti riuscite a sostenere le spese piuttosto bene, ad occhio e croce e anche a guadagnarci.

La morale e': alcune domande apparentemente "STUPIDE", quando arrivano come DOMANDE e quando arrivano da utenti che non sono nel mondo IT sono pericolosamente "creative".

Perche' in effetti, un modello diverso di social network e' assolutamente possibile, almeno sul piano tecnologico.Basta condividere i metadati anziche' i dati, sul modello torrent, e lasciare che chi li vuole li scarichi dalla sorgente.

Uriel