In questo articolo vi presento le mie riflessioni sulla storia e le prospettive di sviluppo di Internet, delle reti centralizzate e decentralizzate e, di conseguenza, sulla possibile architettura della rete decentralizzata di nuova generazione.

C'è qualcosa che non va in Internet

Ho conosciuto Internet per la prima volta nel 2000. Certo, non è l'inizio: la rete esisteva già prima di questo, ma quel periodo può essere considerato come il primo fiorire di Internet. Il World Wide Web è una invenzione geniale di Tim Berners-Lee, web1.0 nella sua forma classica e canonica. Un numero enorme di siti e pagine che si rimandano l'un l'altro tramite collegamenti ipertestuali. A prima vista, un'architettura semplice, come tutte le cose geniali: decentralizzata e libera. Posso visitare i siti di altre persone, seguendo i collegamenti ipertestuali; posso creare il mio sito dove pubblico ciò che mi interessa, come ad esempio i miei articoli, foto, programmi, collegamenti a siti che trovo interessanti. E altri inseriscono collegamenti a me.

Sembrerebbe un quadro idilliaco? Ma già sapete come è andata a finire.

Ci sono troppe pagine e la ricerca di informazioni è diventata un compito piuttosto complesso. I link ipertestuali creati dagli autori non riuscivano a strutturare questa enorme quantità di dati. All'inizio sono apparsi cataloghi popolati manualmente, seguiti da enormi motori di ricerca che hanno iniziato a utilizzare algoritmi di ranking ingegnosi e euristici. I siti web venivano creati e poi abbandonati, le informazioni venivano duplicate e distorte. Internet si commercializzava rapidamente, allontanandosi sempre più dalla rete accademica ideale. Il linguaggio di markup si è rapidamente trasformato in un linguaggio di formattazione. Sono comparsi gli annunci pubblicitari, orribili banner invasivi e la tecnologia di promozione e inganno dei motori di ricerca - SEO. La rete si riempiva rapidamente di spazzatura informativa. I link ipertestuali hanno smesso di essere uno strumento di connessione logica, trasformandosi in uno strumento di promozione. I siti web si chiudevano in se stessi, passavano da 'pagine' aperte a 'app' ermetiche, diventando solo mezzi per generare reddito.

Già allora mi era venuta in mente una certa idea, che "qualcosa qui non va". Una miriade di siti diversi, che vanno da semplici pagine personali con un design stridente, a "megaportali" sovraccarichi di banner lampeggianti. Anche se i siti trattano lo stesso argomento — non hanno nulla in comune, ognuno ha il proprio design, la propria struttura, banner fastidiosi, ricerca poco funzionante, problemi con il download (sì, volevo avere informazioni offline). Già allora, Internet iniziava a diventare una sorta di televisione, dove a contenuti utili venivano inchiodati vari fronzoli.
La decentralizzazione si è trasformata in un incubo.

Cosa si desidera?

Paradossalmente, già allora, senza sapere nulla di web 2.0 o p2p, come utente non avevo bisogno di decentralizzazione! Ripensando alle mie riflessioni pure di quel periodo, giungo alla conclusione che avevo bisogno di... un'unica base di dati! Un tipo di richiesta che fornirebbe tutti i risultati, e non solo quelli più adatti per l'algoritmo di ranking. Un tipo in cui tutti questi risultati sarebbero presentati in modo uniforme e stilizzati secondo il mio stesso design, e non con i terribili design fai-da-te di molti Vasya Pupkin. Un tipo che potrei salvare offline senza temere che il sito scompaia domani e che le informazioni vengano perse per sempre. Un tipo in cui potrei inserire le mie informazioni — ad esempio commenti e tag. Un tipo in cui potrei effettuare ricerche, ordinamenti e filtraggi con i miei algoritmi personali.

Web 2.0 e social media

Nel frattempo, è emersa la concezione di Web 2.0. Formulata nel 2005 da Tim O'Reilly come «metodologia di progettazione di sistemi che, tenendo conto delle interazioni online, diventano migliori man mano che più persone li utilizzano» — implicando un coinvolgimento attivo degli utenti nella creazione e modifica collettiva dei contenuti del web. Senza esagerare, il culmine e il trionfo di questa concezione sono stati i Social Network. Giganti piattaforme che uniscono miliardi di utenti e conservano centinaia di petabyte di dati.

Cosa abbiamo ottenuto nei social network?

unificazione dell'interfaccia; è emerso che tutte le possibilità di creare design variopinti e stravaganti non sono necessarie per gli utenti; tutte le pagine di tutti gli utenti hanno lo stesso design e questo va bene per tutti ed è anche comodo; l'unica cosa che cambia è il contenuto.
unificazione delle funzionalità; la varietà di script si è rivelata anch'essa superflua. «Feed», amici, album... nel corso dell'esistenza dei social network, le loro funzionalità si sono stabilizzate e difficilmente cambieranno: infatti, le funzionalità sono determinate dai tipi di attività delle persone, e le persone non cambiano praticamente.
unica BDA; lavorare con un'unica BDA è molto più comodo rispetto a molti siti disgiunti; la ricerca è diventata molto più semplice. Invece di una scansione continua di pagine debolmente collegate, caching di tutto questo, e classificazione con algoritmi euristici complessi — una relativa semplice richiesta unificata a un'unica base con una struttura nota.
interfaccia di feedback — mi piace e condividi; nel web tradizionale, Google non riusciva a ricevere feedback dagli utenti dopo aver cliccato su un link nei risultati di ricerca. Nei social media, questa connessione è risultata semplice e naturale.

Cosa abbiamo perso? Abbiamo perso la decentralizzazione, e quindi — la libertà. Si ritiene che ora i nostri dati non ci appartengano più. Se prima potevamo ospitare la nostra homepage su un computer personale, ora diamo tutti i nostri dati ai giganti di Internet.

Inoltre, con l'evoluzione di Internet, governi e corporazioni hanno mostrato interesse, il che ha portato a problemi di censura politica e restrizioni sul copyright. Le nostre pagine sui social media possono essere vietate e rimosse se il contenuto non rispetta determinate regole della piattaforma; un post impulsivo può comportare responsabilità amministrativa e persino penale.

E così ci ritroviamo a riflettere: non dovremmo cercare di ripristinare la decentralizzazione? Ma in una forma diversa, priva dei difetti del primo tentativo?

Reti di peering

Le prime reti p2p sono emerse molto prima del web 2.0 e si sono sviluppate parallelamente all'evoluzione del web. L'uso classico principale del p2p è lo scambio di file; le prime reti sono state progettate per condividere musica. Le prime reti (come Napster) erano sostanzialmente centralizzate, e per questo i detentori dei diritti d'autore le hanno rapidamente sotto chiave. I successori hanno seguito la strada della decentralizzazione. Nel 2000 sono apparsi i protocolli ED2K (primo client eDonkey) e Gnutella, e nel 2001 è stato introdotto il protocollo FastTrack (client KaZaA). Gradualmente, il grado di decentralizzazione è aumentato e le tecnologie sono migliorate. A sostegno dei sistemi con "lista d'attesa" sono arrivati i torrent, e si è sviluppata la concezione delle tabelle hash distribuite DHT. Con il giro di vite da parte degli stati, l'anonimato dei partecipanti è diventato sempre più richiesto. Dal 2000 è in corso lo sviluppo della rete Freenet, dal 2003 di I2P, e nel 2006 è stato avviato il progetto RetroShare. Si possono menzionare numerose reti p2p, sia quelle esistite in passato e già scomparse, sia quelle attualmente attive: WASTE, MUTE, TurtleF2F, RShare, PerfectDark, ARES, Gnutella2, GNUNet, IPFS, ZeroNet, Tribbler e molte altre. Ce ne sono molte. Sono diverse. Molto diverse — sia per scopo che per struttura... Probabilmente non tutti voi conoscete nemmeno tutti questi nomi. E non è affatto tutto.

Tuttavia, le reti p2p hanno molti svantaggi. Oltre ai difetti tecnici inerenti a ciascuna specifica implementazione del protocollo e del client, si può notare un difetto piuttosto comune: la difficoltà di ricerca (ossia, tutto ciò con cui si è confrontato il Web 1.0, ma in una forma ancora più complessa). Non esiste un Google con la sua ricerca onnipresente e immediata. E se per le reti di file sharing è ancora possibile utilizzare la ricerca per nome del file o per metainformazioni, trovare qualcosa, ad esempio, nelle reti overlay onion o i2p, è piuttosto difficile, se non impossibile.

In generale, se si fanno analogie con l'internet classico, la maggior parte delle reti decentralizzate è bloccata a un livello simile a quello di FTP. Immagina un internet in cui non esiste nulla tranne FTP: nessun sito moderno, nessun web2.0, nessun Youtube... Questa è circa la condizione attuale delle reti decentralizzate. E nonostante i singoli tentativi di apportare modifiche, finora i cambiamenti sono pochi.

Contenuto

Tornando a un altro pezzo importante di questo puzzle: il contenuto. Il contenuto è il problema principale di qualsiasi risorsa online, in particolare di quella decentralizzata. Da dove prenderlo? Certo, si può contare su un gruppo di appassionati (come accade con le attuali reti p2p), ma allora lo sviluppo della rete sarà piuttosto lento e il contenuto scarso.

Lavorare con il web tradizionale significa cercare e studiare contenuti. A volte, significa anche salvarli (se il contenuto è interessante e utile, molti, specialmente quelli che sono arrivati in rete ai tempi del dial-up — me compreso — prudentemente lo salvano offline, per non perderlo; perché internet è una cosa al di fuori del nostro controllo, oggi un sito esiste, domani no, oggi c'è un video su YouTube — domani potrebbe essere rimosso, e così via.

E per i torrent (che consideriamo più un mezzo di consegna che una rete p2p) il salvataggio è previsto. E questo, tra l'altro, è uno dei problemi dei torrent: un file scaricato una volta è difficile spostarlo dove è più comodo utilizzarlo (di solito è necessario rigenerare manualmente la condivisione) e non può essere rinominato (è possibile creare un hard link, ma molto pochi lo sanno).

In generale, molti in un modo o nell'altro salvano contenuti. Qual è il loro destino successivo? Di solito, i file salvati si trovano da qualche parte sul disco, in una cartella tipo Downloads, in un grande cumulo, e rimangono lì insieme a molte altre migliaia di file. Questo è un problema, e per di più, è un problema per l'utente stesso. Se su Internet ci sono motori di ricerca, il computer locale dell'utente non ha niente di simile. È una fortuna se l'utente è ordinato e abituato a classificare i file scaricati 'in arrivo'. Ma non tutti sono così...

In realtà, ci sono molti che non salvano nulla e si affidano completamente al cloud. Ma nelle reti p2p si presume che il contenuto venga memorizzato localmente sul dispositivo dell'utente e condiviso con altri partecipanti. È possibile trovare una soluzione che coinvolga entrambe le categorie di utenti in una rete decentralizzata, senza cambiare le loro abitudini e, anzi, facilitando la loro vita?

L'idea è piuttosto semplice: e se creassimo uno strumento per il salvataggio comodo e trasparente dei contenuti da Internet, salvando in modo intelligente - con metainformazioni semantiche, non in un'unica massa, ma in una struttura specifica con la possibilità di ulteriore strutturazione, e allo stesso tempo condividendo il contenuto salvato in una rete decentralizzata?

Iniziamo con il salvataggio

Non ci occuperemo dell'uso utilitaristico di Internet per consultare previsioni del tempo o orari dei voli. Ci interessano di più oggetti autonomi e relativamente immutabili: articoli (dai tweet/post sui social ai lunghi articoli, proprio come qui su Habr), libri, immagini, programmi, registrazioni audio e video. Da dove proviene principalmente l'informazione? Di solito è

i social network (notizie varie, brevi note - "tweet", immagini, audio e video)
articoli su risorse tematiche (tipo Habr); non ci sono molte buone risorse, di solito queste risorse sono anch'esse strutturate come social network
siti di notizie

Di solito, ci sono funzioni standard: "mi piace", "condividi", "condividi sui social" e così via.

Immaginiamo un plugin per il browser, che salverà in modo speciale tutto ciò che abbiamo messo 'mi piace', condiviso, aggiunto ai 'preferiti' (o premuto il pulsante speciale del plugin, mostrato nel menu del browser - nel caso in cui il sito non abbia la funzione di 'mi piace'/condivisione/aggiunta ai segnalibri). L'idea principale è che tu metti semplicemente 'mi piace' - come hai fatto milioni di volte prima, e il sistema salva l'articolo, l'immagine o il video in un'apposita archiviazione offline, rendendo disponibile quell'articolo o quell'immagine - sia per la visualizzazione offline tramite l'interfaccia del client decentralizzato, sia nella rete decentralizzata stessa! A mio avviso, è molto comodo. Nessuna azione superflua, e risolviamo subito molte questioni:

salvare contenuti preziosi che potrebbero andare persi o essere cancellati
riempimento rapido della rete decentralizzata
aggregazione di contenuti provenienti da diverse fonti (puoi essere registrato su decine di risorse online, e tutti i 'mi piace'/condivisioni confluiranno in un'unica base locale)
strutturare contenuti interessanti per te secondo le tue regole

È evidente che il plugin per il browser debba essere adattato alla struttura di ciascun sito web (è del tutto possibile: esistono già plugin per il salvataggio dei contenuti da Youtube, Twitter, VK, ecc.). I siti per i quali vale la pena creare plugin personalizzati non sono molti. Di solito, si tratta di social network diffusi (ne esistono appena una decina) e di un certo numero di siti tematici di alta qualità come Habr (anch'essi sono rari). Con un codice aperto e una specifica, lo sviluppo di un nuovo plugin basato su un modello predefinito non dovrebbe richiedere molto tempo. Per gli altri siti, si può utilizzare un pulsante universale per il salvataggio, che salverebbe l'intera pagina in formato mhtml — possibilmente, dopo aver rimosso la pubblicità dalla pagina.

Ora sulla strutturazione

Per «salvataggio intelligente» intendo almeno un salvataggio con metainformazioni: fonte del contenuto (URL), insieme di like precedentemente espressi, tag, commenti, i loro identificativi, ecc. Infatti, con un salvataggio normale, queste informazioni vengono perse... La fonte può includere non solo l'URL diretto, ma anche l'aspetto semantico: ad esempio, un gruppo sui social media o l'utente che ha effettuato un repost. Il plugin potrebbe essere sufficientemente intelligente da utilizzare queste informazioni per una strutturazione e un tagging automatici. Inoltre, va compreso che l'utente stesso può sempre aggiungere metainformazioni al contenuto salvato, per cui dovrebbero essere previsti strumenti di interfaccia il più comodi possibile (ho molte idee su come fare).

In questo modo, viene affrontata la questione della strutturazione e dell'organizzazione dei file locali dell'utente. Si tratta già di un vantaggio pronto all'uso, di cui si può usufruire anche senza alcun p2p. È semplicemente un database offline che sa cosa, da dove e in quale contesto abbiamo salvato, e consente di condurre piccole ricerche. Ad esempio, per trovare utenti di un social network esterno che hanno messo più mi piace agli stessi post che hai messo tu. Molti social network consentono questo in modo esplicito?

Qui è importante menzionare che un solo plugin per il browser non è ovviamente sufficiente. Il secondo componente fondamentale del sistema è un servizio di rete decentralizzata che opera in background e gestisce sia la rete p2p stessa (richieste dalla rete e richieste da parte del cliente), sia il salvataggio di nuovi contenuti tramite il plugin. Il servizio, lavorando insieme al plugin, posizionerà il contenuto nel luogo corretto, calcolerà gli hash (e potrebbe anche determinare se quel contenuto è già stato salvato in precedenza) e aggiungerà le informazioni meta necessarie al database locale.

Ciò che è interessante è che il sistema sarebbe utile anche in questa forma, senza alcun p2p. Molti utilizzano i web clipper per aggiungere contenuti interessanti dal web, ad esempio in Evernote. L'architettura proposta è una versione avanzata di tale clipper.

E infine, lo scambio p2p

La cosa più piacevole è che è possibile scambiare informazioni e meta-informazioni (sia quelle catturate dal web che le proprie). Il concetto di social network si adatta perfettamente all'architettura p2p. Si può dire che i social network e il p2p siano fatti l'uno per l'altro. Qualsiasi rete decentralizzata dovrebbe idealmente essere costruita come un sociale; solo allora funzionerà in modo efficace. 'Amici', 'Gruppi' sono proprio quei nodi con cui dovrebbero esserci collegamenti stabili, e questi nascono da una fonte naturale: gli interessi comuni degli utenti.

I principi di conservazione e condivisione dei contenuti in una rete decentralizzata sono completamente identici a quelli di conservazione (cattura) dei contenuti da internet tradizionale. Se utilizzi un contenuto dalla rete (e quindi lo hai salvato), chiunque può utilizzare le tue risorse (disco e banda) necessarie per accedere a quel contenuto specifico.

Mi piace è lo strumento più semplice per salvare e condividere. Se metto un mi piace — sia su internet tradizionale che all'interno della rete decentralizzata — significa che il contenuto mi piace, e dato ciò — sono pronto a conservarlo localmente e a condividerlo con altri membri della rete decentralizzata.

Il contenuto non "andarà perso"; ora è salvato localmente, posso tornare ad esso in qualsiasi momento, senza preoccuparmi che qualcuno lo cancelli o lo blocchi.
Posso (immediatamente o in seguito) categorizzarlo, etichettarlo, commentarlo, associarlo ad altri contenuti, insomma fare qualcosa di significativo — chiamiamolo "formazione di meta-informazioni".
Posso condividere queste meta-informazioni con altri membri della rete.
Posso sincronizzare la mia meta-informazione con quella di altri partecipanti

Probabilmente, rinunciare ai dislike ha anche un senso: se un contenuto non mi piace, è logico che non voglia spendere il mio spazio di archiviazione e la mia connessione Internet per distribuirlo. Pertanto, i dislike non si integrano affatto nella decentralizzazione (anche se a volte può ancora essere utile).

A volte è necessario conservare anche ciò che "non piace". C'è una parola, "deve":)
«Segnalibri» (o "Preferiti") — non esprimo un giudizio sul contenuto, ma lo salvo nella mia base locale di segnalibri. La parola "preferiti" non si adatta esattamente al significato (per questo ci sono i like e la loro successiva categorizzazione), mentre "segnalibri" si adatta perfettamente. I contenuti nei "segnalibri" vengono anche distribuiti — se ti serve (cioè se in qualche modo lo "usi"), è logico che possa servire anche a qualcun altro. Perché non utilizzare le tue risorse per questo?

La funzione è piuttosto ovvia "amici«. Sono gruppi, persone con interessi simili, il che significa che probabilmente avranno contenuti interessanti. In una rete decentralizzata, questo significa principalmente iscriversi al feed delle notizie degli amici e avere accesso ai loro cataloghi (album) con i contenuti che hanno salvato.

Analogamente, la funzione «gruppi» è un certo tipo di feed collettivo, o forum, o qualcosa del genere, a cui è possibile iscriversi e quindi ricevere tutti i materiali del gruppo e condividerli. È possibile che i «gruppi», simili a grandi forum, debbano essere gerarchici — questo permetterebbe di strutturare meglio i contenuti dei gruppi e di limitare il flusso di informazioni, evitando di ricevere o condividere ciò che non è particolarmente interessante per te.

Tutto il resto

Va notato che l'architettura decentralizzata è sempre più complessa rispetto a quella centralizzata. Nei sistemi centralizzati, esiste un'autorità rigida del codice server. In quelli decentralizzati, c'è la necessità di accordarsi tra molti partecipanti uguali. Naturalmente, non si può fare a meno della crittografia, delle blockchain e di altre innovazioni, sviluppate principalmente nel campo delle criptovalute.

Credo sia necessario stabilire alcuni sistemi di valutazione crittografici reciproci, creati dai membri della rete l'uno per l'altro. L'architettura dovrebbe consentire di combattere in modo efficace i botnet, che, esistendo in una sorta di nube, potrebbero ad esempio gonfiare i propri rating. È fondamentale che le corporation e le fattorie di botnet, nonostante il loro indiscusso potere tecnologico, non possano prendere il controllo di una rete decentralizzata; l'elemento chiave devono essere le persone reali, capaci di creare e strutturare contenuti interessanti e utili per altri esseri umani.

Vorrei anche che una rete del genere spingesse la civiltà verso il progresso. Ho un'intera serie di idee a riguardo, che però non rientrano nei limiti di questo articolo. Possiamo dire soltanto che, in un certo senso, i contenuti scientifici, tecnici, medici, ecc., dovrebbero avere un vantaggio su quelli di intrattenimento, il che richiederà una certa moderazione. La moderazione di una rete decentralizzata è un compito non banale, ma realizzabile (anche se il termine «moderazione» qui è del tutto inappropriato e non riflette la vera essenza del processo — né esternamente né internamente… e non ho nemmeno trovato un modo per definire questo processo).

Probabilmente è superfluo menzionare la necessità di garantire l'anonimato — sia tramite mezzi integrati (come in i2p o Retroshare), sia instradando tutto il traffico attraverso TOR o VPN.

E infine, l'architettura software (schematicamente rappresentata nell'immagine dell'articolo). Come già detto, il primo componente del sistema è un plugin per il browser che cattura il contenuto con le meta-informazioni. Il secondo componente fondamentale è un servizio p2p che opera in background («backend»). È evidente che il funzionamento della rete non deve dipendere dall'apertura del browser. Il terzo componente è il software client — frontend. Questo può essere un servizio web locale (in questo caso, l'utente potrà lavorare con la rete decentralizzata senza uscire dal proprio browser preferito) o un'applicazione GUI separata per un sistema operativo specifico (Windows, Linux, MacOS, Android, iOS, ecc.). Mi piace l'idea di avere tutte le varianti del frontend contemporaneamente. Questo, a sua volta, richiederà un'architettura del backend più rigorosa.

Ci sono molti altri aspetti che non sono stati trattati in questo articolo. La connessione a sorgenti di file esistenti (ossia quando hai già diversi terabyte di contenuti scaricati e permetti al cliente di scansionarli, ottenere gli hash, confrontarli con quelli presenti in rete e unirsi alla condivisione, oltre a ricevere dalla rete metainformazioni sui propri file — nomi, descrizioni, classifiche, recensioni, ecc.), la connessione a fonti esterne di metainformazioni (ad esempio, banche dati come Libgen), l'uso facoltativo dello spazio su disco per memorizzare contenuti crittografati di terzi (come in Freenet), l'architettura di integrazione con reti decentralizzate esistenti (qui è un vero e proprio campo minato), l'idea della media hashing (utilizzo di hash percettivi speciali per contenuti multimediali — immagini, audio e video, che permetterà di confrontare file multimediali con significati simili, ma con dimensioni e risoluzioni diverse, ecc.) e molto altro.

Sintesi breve dell'articolo

1. Nelle reti decentralizzate non esiste Google con la sua ricerca e classificazione, ma c'è una comunità di persone reali. Un social network con i suoi meccanismi di feedback (like, condivisioni…) e la mappa sociale (amici, comunità…) rappresenta un modello ideale per il livello applicativo di una rete decentralizzata.
2. Il concetto principale che introduco con questo articolo è il salvataggio automatico di contenuti interessanti dal web tradizionale al momento di un like/condivisione; ciò può essere utile anche senza p2p, semplicemente per gestire un archivio personale di informazioni interessanti.
3. Questo contenuto può anche riempire automaticamente la rete decentralizzata.
4. Il principio del salvataggio automatico di contenuti interessanti si applica anche ai like/condivisioni all'interno della stessa rete decentralizzata.

Fonte: habr.com