Dans cet article, je vous présente mes réflexions sur l'histoire et les perspectives de développement d'Internet, des réseaux centralisés et décentralisés et, par conséquent, l'architecture possible du réseau décentralisé de nouvelle génération.

Il y a quelque chose qui ne va pas avec Internet

J'ai découvert Internet pour la première fois en 2000. Bien sûr, ce n'est pas le tout début - le réseau existait déjà avant cela, mais cette époque peut être qualifiée de premier apogée d'Internet. Le World Wide Web est l'ingénieuse invention de Tim Berners-Lee, le web1.0 dans sa forme canonique classique. De nombreux sites et pages sont reliés entre eux par des hyperliens. À première vue, l’architecture est simple, comme toutes les choses ingénieuses : décentralisé et gratuit. Je veux - Je voyage vers les sites d'autres personnes en suivant des hyperliens ; Je souhaite créer mon propre site internet sur lequel je publie ce qui m'intéresse - par exemple, mes articles, photographies, programmes, hyperliens vers des sites qui m'intéressent. Et d’autres me publient des liens.

Cela semblerait être une image idyllique ? Mais vous savez déjà comment tout cela s'est terminé.

Il y a trop de pages et la recherche d'informations est devenue une tâche très non triviale. Les hyperliens prescrits par les auteurs ne pouvaient tout simplement pas structurer cette énorme quantité d'informations. Il y a d’abord eu des répertoires remplis manuellement, puis des moteurs de recherche géants qui ont commencé à utiliser d’ingénieux algorithmes de classement heuristique. Des sites Web ont été créés et abandonnés, des informations ont été dupliquées et déformées. Internet se commercialisait rapidement et s’éloignait du réseau universitaire idéal. Le langage de balisage est rapidement devenu un langage de formatage. La publicité est apparue, de méchantes bannières ennuyeuses et une technologie pour promouvoir et tromper les moteurs de recherche - le référencement. Le réseau était rapidement encombré de déchets d’informations. Les hyperliens ont cessé d'être un outil de communication logique et sont devenus un outil de promotion. Les sites Web se sont fermés sur eux-mêmes, sont passés de « pages » ouvertes à des « applications » fermées et sont devenus de simples moyens de générer des revenus.

Même à ce moment-là, j’avais l’impression que « quelque chose ne va pas ici ». Un tas de sites différents, allant de pages d'accueil primitives aux yeux écarquillés, jusqu'à des « méga-portails » surchargés de bannières clignotantes. Même si les sites sont sur le même sujet, ils ne sont pas du tout liés, chacun a son propre design, sa propre structure, des bannières gênantes, une recherche qui fonctionne mal, des problèmes de téléchargement (oui, je voulais avoir des informations hors ligne). Même alors, Internet commençait à se transformer en une sorte de télévision, où toutes sortes de guirlandes étaient attachées à un contenu utile.
La décentralisation est devenue un cauchemar.

Que veux-tu?

C’est paradoxal, mais même alors, ne connaissant pas encore le web 2.0 ou le p2p, en tant qu’utilisateur, je n’avais pas besoin de décentralisation ! En me souvenant de mes pensées claires de cette époque, j'arrive à la conclusion que j'avais besoin... base de données unifiée! Une telle requête renverrait tous les résultats, et non ceux qui conviennent le mieux à l'algorithme de classement. Un modèle dans lequel tous ces résultats seraient conçus de manière uniforme et stylisés par mon propre design uniforme, et non par les designs auto-réalisés de nombreux Vasya Pupkins. Celui qui pourrait être sauvegardé hors ligne et ne pas avoir peur que demain le site disparaisse et que les informations soient perdues à jamais. Celui dans lequel je pourrais saisir mes informations, telles que des commentaires et des tags. Celui dans lequel je pourrais rechercher, trier et filtrer avec mes propres algorithmes personnels.

Web 2.0 et réseaux sociaux

Entre-temps, le concept du Web 2.0 est entré dans l’arène. Formulée en 2005 par Tim O'Reilly comme « une technique de conception de systèmes qui, en prenant en compte les interactions réseau, s'améliorent à mesure que les gens les utilisent » - et implique l'implication active des utilisateurs dans la création et l'édition collectives du contenu Web. Sans exagération, le summum et le triomphe de ce concept furent les réseaux sociaux. Des plateformes géantes qui connectent des milliards d’utilisateurs et stockent des centaines de pétaoctets de données.

Qu'a-t-on reçu sur les réseaux sociaux ?

• unification des interfaces ; il s'est avéré que les utilisateurs n'ont pas besoin de toutes les opportunités pour créer une variété de designs accrocheurs ; toutes les pages de tous les utilisateurs ont le même design et cela convient à tout le monde et est même pratique ; Seul le contenu est différent.
• unification des fonctionnalités; toute la variété des scripts s'est avérée inutile. "Flux", amis, albums... au cours de l'existence des réseaux sociaux, leur fonctionnalité s'est plus ou moins stabilisée et il est peu probable qu'elle change : après tout, la fonctionnalité est déterminée par les types d'activités des personnes, et les gens ne changent pratiquement pas .
• base de données unique ; il s'est avéré beaucoup plus pratique de travailler avec une telle base de données qu'avec de nombreux sites disparates ; la recherche est devenue beaucoup plus facile. Au lieu d'analyser continuellement une variété de pages vaguement liées, de tout mettre en cache, de les classer à l'aide d'algorithmes heuristiques complexes - une requête unifiée relativement simple sur une base de données unique avec une structure connue.
• interface de commentaires - likes et republications ; sur le Web classique, le même Google ne pouvait pas obtenir de commentaires des utilisateurs après avoir suivi un lien dans les résultats de recherche. Sur les réseaux sociaux, cette connexion s’est révélée simple et naturelle.

Qu'avons-nous perdu? Nous avons perdu la décentralisation, ce qui signifie la liberté. On pense que nos données ne nous appartiennent plus. Si auparavant nous pouvions placer une page d'accueil même sur notre propre ordinateur, nous donnons désormais toutes nos données aux géants de l'Internet.

De plus, à mesure qu’Internet se développait, les gouvernements et les entreprises s’y intéressaient, ce qui soulevait des problèmes de censure politique et de restrictions des droits d’auteur. Nos pages sur les réseaux sociaux peuvent être interdites et supprimées si le contenu ne respecte aucune règle du réseau social ; pour un poste imprudent - engager une responsabilité administrative, voire pénale.

Et maintenant, nous réfléchissons à nouveau : ne devrions-nous pas revenir à la décentralisation ? Mais sous une forme différente, dépourvue des défauts du premier essai ?

Réseaux peer-to-peer

Les premiers réseaux p2p sont apparus bien avant le web 2.0 et se sont développés parallèlement au développement du web. La principale application classique du p2p est le partage de fichiers ; les premiers réseaux furent développés pour l'échange de musique. Les premiers réseaux (comme Napster) étaient essentiellement centralisés et ont donc été rapidement fermés par les détenteurs de droits d'auteur. Les adeptes ont suivi la voie de la décentralisation. En 2000, les protocoles ED2K (le premier client eDokney) et Gnutella sont apparus, en 2001 - le protocole FastTrack (client KaZaA). Peu à peu, le degré de décentralisation s'est accru et les technologies se sont améliorées. Les systèmes de « file d’attente de téléchargement » ont été remplacés par des torrents, et le concept de tables de hachage distribuées (DHT) est apparu. À mesure que les États resserrent la vis, l’anonymat des participants est de plus en plus demandé. Le réseau Freenet est développé depuis 2000, I2003P depuis 2 et le projet RetroShare lancé en 2006. On peut citer de nombreux réseaux p2p, à la fois existants et déjà disparus, et actuellement opérationnels : WASTE, MUTE, TurtleF2F, RShare, PerfectDark, ARES, Gnutella2, GNUNet, IPFS, ZeroNet, Tribbler et bien d'autres. Beaucoup d'entre eux. Ils sont différents. Très différent - à la fois dans son objectif et dans sa conception... Beaucoup d'entre vous ne connaissent probablement même pas tous ces noms. Et ce n'est pas tout.

Cependant, les réseaux p2p présentent de nombreux inconvénients. Outre les défauts techniques inhérents à chaque protocole spécifique et implémentation client, on peut par exemple noter un inconvénient assez général : la complexité de la recherche (c'est-à-dire tout ce que le Web 1.0 a rencontré, mais dans une version encore plus complexe). Il n’y a pas de Google ici avec sa recherche omniprésente et instantanée. Et si pour les réseaux de partage de fichiers, vous pouvez toujours utiliser une recherche par nom de fichier ou par méta-informations, alors trouver quelque chose, par exemple, dans les réseaux de superposition oignon ou i2p est très difficile, voire impossible.

En général, si nous faisons des analogies avec l'Internet classique, alors la plupart des réseaux décentralisés sont bloqués quelque part au niveau FTP. Imaginez un Internet dans lequel il n'y a que FTP : pas de sites modernes, pas de web2.0, pas de Youtube... C'est à peu près l'état des réseaux décentralisés. Et malgré les tentatives individuelles pour changer quelque chose, il y a peu de changements jusqu’à présent.

contenu

Passons à une autre pièce importante de ce puzzle : le contenu. Le contenu est le principal problème de toute ressource Internet, et surtout décentralisée. Où l'obtenir ? Bien sûr, vous pouvez compter sur une poignée de passionnés (comme c'est le cas avec les réseaux p2p existants), mais alors le développement du réseau sera assez long, et il y aura peu de contenu.

Travailler avec Internet classique signifie rechercher et étudier du contenu. Parfois - sauvegarde (si le contenu est intéressant et utile, alors beaucoup, en particulier ceux qui sont venus sur Internet à l'époque de la connexion commutée - moi y compris - le sauvegardent prudemment hors ligne afin de ne pas se perdre ; parce qu'Internet est une chose hors de notre contrôle, aujourd'hui le site est là, demain il n'y en a pas, aujourd'hui il y a une vidéo sur YouTube - demain elle sera supprimée, etc.

Et pour les torrents (que nous percevons plus comme un simple moyen de diffusion que comme un réseau p2p), la sauvegarde est généralement implicite. Et c'est d'ailleurs l'un des problèmes des torrents : un fichier téléchargé une fois est difficile à déplacer là où il est plus pratique à utiliser (en règle générale, vous devez régénérer manuellement la distribution) et ne peut absolument pas être renommé ( vous pouvez le relier en dur, mais très peu de gens le savent).

En général, de nombreuses personnes sauvegardent du contenu d’une manière ou d’une autre. Quel est son futur destin ? En règle générale, les fichiers enregistrés se retrouvent quelque part sur le disque, dans un dossier tel que Téléchargements, dans le tas général, et s'y trouvent avec plusieurs milliers d'autres fichiers. C'est mauvais – et mauvais pour l'utilisateur lui-même. Si Internet dispose de moteurs de recherche, l’ordinateur local de l’utilisateur n’a rien de similaire. C'est bien si l'utilisateur est soigné et habitué à trier les fichiers téléchargés « entrants ». Mais tout le monde n'est pas comme ça...

En fait, nombreux sont désormais ceux qui n’économisent rien, mais qui comptent entièrement sur Internet. Mais dans les réseaux p2p, on suppose que le contenu est stocké localement sur l’appareil de l’utilisateur et distribué aux autres participants. Est-il possible de trouver une solution qui permettra aux deux catégories d’utilisateurs de s’impliquer dans un réseau décentralisé sans changer leurs habitudes, et qui plus est, en leur facilitant la vie ?

L'idée est assez simple : et si nous créions un moyen de sauvegarde du contenu de l'Internet classique, pratique et transparent pour l'utilisateur, et une sauvegarde intelligente - avec des méta-informations sémantiques, et non pas dans un tas commun, mais dans une structure spécifique avec la possibilité de structurer davantage, et en même temps de distribuer le contenu enregistré sur un réseau décentralisé ?

Commençons par économiser

Nous ne considérerons pas l’usage utilitaire d’Internet pour consulter les prévisions météorologiques ou les horaires d’avion. Nous nous intéressons davantage aux objets autosuffisants et plus ou moins immuables - les articles (des tweets/posts des réseaux sociaux aux gros articles, comme ici sur Habré), les livres, les images, les programmes, les enregistrements audio et vidéo. D’où proviennent principalement les informations ? Habituellement ceci

• réseaux sociaux (actualités diverses, petites notes - « tweets », photos, audio et vidéo)
• des articles sur des ressources thématiques (telles que Habr) ; Il n'y a pas beaucoup de bonnes ressources, généralement ces ressources sont également construites sur le principe des réseaux sociaux
• sites d'actualités

En règle générale, il existe des fonctions standards : « like », « repost », « partager sur les réseaux sociaux », etc.

Imaginons quelques plugin de navigateur, qui enregistrera spécialement tout ce que nous avons aimé, republié, enregistré dans les « favoris » (ou cliqué sur un bouton de plugin spécial affiché dans le menu du navigateur - au cas où le site n'aurait pas de fonction like/repost/bookmark). L'idée principale est que vous l'aimez simplement - comme vous l'avez fait un million de fois auparavant, et le système enregistre l'article, l'image ou la vidéo dans un stockage hors ligne spécial et cet article ou cette image devient disponible - et vous permet de le visionner hors ligne via le interface client décentralisée, et dans le réseau le plus décentralisé ! À mon avis, c'est très pratique. Il n'y a pas d'actions inutiles et nous résolvons de nombreux problèmes à la fois :

• Préserver le contenu précieux qui pourrait être perdu ou supprimé
• remplissage rapide du réseau décentralisé
• agrégation de contenu provenant de différentes sources (vous pouvez être inscrit sur des dizaines de ressources Internet, et tous les likes/reposts seront regroupés dans une seule base de données locale)
• structurer le contenu qui vous intéresse selon le vôtre les règles

Évidemment, le plugin du navigateur doit être configuré pour la structure de chaque site (c'est tout à fait réaliste - il existe déjà des plugins pour sauvegarder le contenu de Youtube, Twitter, VK, etc.). Il n'y a pas tellement de sites pour lesquels il est logique de créer des plugins personnels. En règle générale, il s'agit de réseaux sociaux courants (il n'y en a guère plus d'une douzaine) et de nombreux sites thématiques de qualité comme Habr (il en existe également quelques-uns). Avec du code et des spécifications open source, développer un nouveau plugin basé sur un modèle ne devrait pas prendre beaucoup de temps. Pour d'autres sites, vous pouvez utiliser un bouton de sauvegarde universel, qui enregistrerait la page entière au format mhtml - peut-être après avoir d'abord effacé la page de publicité.

Parlons maintenant de la structuration

Par sauvegarde « intelligente », j'entends au moins une sauvegarde avec des méta-informations : la source du contenu (URL), un ensemble de likes préalablement définis, des tags, des commentaires, leurs identifiants, etc. Après tout, lors d'une sauvegarde normale, ces informations sont perdues... La source peut être comprise non seulement comme une URL directe, mais aussi comme un composant sémantique : par exemple, un groupe sur un réseau social ou un utilisateur qui a reposté. Le plugin peut être suffisamment intelligent pour utiliser ces informations pour une structuration et un balisage automatiques. En outre, il faut comprendre que l'utilisateur lui-même peut toujours ajouter des méta-informations au contenu enregistré, pour lequel les outils d'interface les plus pratiques doivent être fournis (j'ai beaucoup d'idées sur la façon de procéder).

Ainsi, la question de la structuration et de l’organisation des fichiers locaux de l’utilisateur est résolue. Il s'agit d'un avantage prêt à l'emploi qui peut être utilisé même sans aucun p2p. Juste une sorte de base de données hors ligne qui sait quoi, où et dans quel contexte nous avons sauvegardé, et nous permet de mener de petites études. Par exemple, recherchez les utilisateurs d’un réseau social externe qui ont le plus aimé les mêmes publications que vous. Combien de réseaux sociaux le permettent explicitement ?

Il convient déjà de mentionner ici qu’un seul plugin de navigateur ne suffit certainement pas. Le deuxième composant le plus important du système est le service réseau décentralisé, qui fonctionne en arrière-plan et sert à la fois le réseau p2p lui-même (demandes du réseau et demandes du client) et la sauvegarde de nouveaux contenus à l'aide du plugin. Le service, en collaboration avec le plugin, placera le contenu au bon endroit, calculera les hachages (et déterminera éventuellement que ce contenu a déjà été enregistré précédemment) et ajoutera les métainformations nécessaires à la base de données locale.

Ce qui est intéressant, c’est que le système serait déjà utile sous cette forme, sans aucun p2p. De nombreuses personnes utilisent des Web Clippers qui ajoutent du contenu intéressant du Web à Evernote, par exemple. L'architecture proposée est une version étendue d'un tel clipper.

Et enfin, l'échange p2p

Le meilleur, c’est que les informations et méta-informations (capturées sur le Web et les vôtres) peuvent être échangées. Le concept de réseau social se transfère parfaitement à l’architecture p2p. On peut dire que le réseau social et le p2p semblent être faits l'un pour l'autre. Tout réseau décentralisé devrait idéalement être construit comme un réseau social, ce n'est qu'alors qu'il fonctionnera efficacement. "Amis", "Groupes" - ce sont les mêmes pairs avec lesquels il devrait y avoir des connexions stables, et ceux-ci proviennent d'une source naturelle - les intérêts communs des utilisateurs.

Les principes de sauvegarde et de distribution de contenu dans un réseau décentralisé sont complètement identiques aux principes de sauvegarde (capture) de contenu à partir d'Internet classique. Si vous utilisez du contenu du réseau (et que vous l'avez donc enregistré), alors n'importe qui peut utiliser vos ressources (disque et canal) nécessaires pour recevoir ce contenu particulier.

Aime — l'outil de sauvegarde et de partage le plus simple. Si je l'ai aimé - que ce soit sur Internet externe ou à l'intérieur du réseau décentralisé - cela signifie que j'aime le contenu, et si c'est le cas, alors je suis prêt à le conserver localement et à le distribuer aux autres participants du réseau décentralisé.

• Le contenu ne sera pas « perdu » ; il est désormais enregistré localement, je peux y revenir plus tard, à tout moment, sans craindre que quelqu'un le supprime ou le bloque
• Je peux (immédiatement ou plus tard) le catégoriser, le taguer, le commenter, l'associer à d'autres contenus et généralement en faire quelque chose de significatif – appelons cela « génération de métainformations ».
• Je peux partager ces méta-informations avec d'autres membres du réseau
• Je peux synchroniser mes méta-informations avec les méta-informations des autres membres

Probablement, renoncer aux aversions semble également logique : si je n'aime pas le contenu, alors il est tout à fait logique que je ne veuille pas gaspiller mon espace disque pour le stockage et mon canal Internet pour distribuer ce contenu. Par conséquent, les aversions ne s’intègrent pas de manière très organique dans la décentralisation (même si cela peut parfois peut être utile).

Parfois, vous devez garder ce que vous « n’aimez pas ». Il existe un mot comme "doit" :)
«Bookmarks» (ou « Favoris ») - Je n'exprime pas d'affinité pour le contenu, mais je l'enregistre dans ma base de données de favoris locale. Le mot « favoris » n'a pas un sens tout à fait approprié (pour cela, il y a des likes et leur catégorisation ultérieure), mais les « signets » conviennent tout à fait. Le contenu des « favoris » est également distribué - si vous en « avez besoin » (c'est-à-dire que vous l'« utilisez » d'une manière ou d'une autre), alors il est logique que quelqu'un d'autre puisse en « avoir besoin ». Pourquoi ne pas utiliser vos ressources pour le faire ?

La fonction "Amis". Il s’agit de pairs, de personnes ayant des intérêts similaires, et donc celles qui sont les plus susceptibles d’avoir un contenu intéressant. Sur un réseau décentralisé, cela signifie principalement s'abonner aux flux d'actualités d'amis et accéder à leurs catalogues (albums) de contenus qu'ils ont enregistrés.

Similaire à la fonction "groupes"- une sorte de flux collectifs, ou de forums, ou quelque chose auquel vous pouvez également vous abonner - et cela signifie accepter tous les documents du groupe et les distribuer. Peut-être que les « groupes », comme les grands forums, devraient être hiérarchiques - cela permettra une meilleure structuration du contenu du groupe, ainsi que de limiter le flux d'informations et de ne pas accepter/distribuer ce qui ne vous intéresse pas beaucoup.

Tout le reste

Il convient de noter qu’une architecture décentralisée est toujours plus complexe qu’une architecture centralisée. Dans les ressources centralisées, le code du serveur est strictement imposé. Dans les pays décentralisés, il est nécessaire de négocier entre de nombreux participants égaux. Bien entendu, cela ne peut se faire sans la cryptographie, les blockchains et autres réalisations développées principalement sur les cryptomonnaies.

Je suppose qu'une sorte d'évaluation de confiance mutuelle cryptographique formée par les participants du réseau les uns pour les autres peut être nécessaire. L'architecture doit permettre de lutter efficacement contre les botnets qui, existant dans un certain cloud, peuvent, par exemple, augmenter mutuellement leurs propres notes. Je veux vraiment que les entreprises et les fermes de botnets, malgré toute leur supériorité technologique, ne prennent pas le contrôle d’un réseau aussi décentralisé ; afin que sa principale ressource soit des personnes vivantes capables de produire et de structurer des contenus intéressants et utiles pour d'autres personnes vivantes.

Je souhaite également qu’un tel réseau fasse avancer la civilisation vers le progrès. J'ai tout un tas d'idées à ce sujet, qui n'entrent cependant pas dans le cadre de cet article. Je dirai seulement que d'une certaine manière scientifique, technique, médicale, etc. le contenu doit primer sur le divertissement, ce qui nécessitera une certaine modération. La modération d'un réseau décentralisé en soi est une tâche non triviale, mais elle peut être résolue (cependant, le mot « modération » ici est complètement incorrect et ne reflète pas du tout l'essence du processus - ni en externe ni en interne... et Je ne pouvais même pas penser à comment ce processus pourrait s'appeler).

Il serait probablement inutile de mentionner la nécessité de garantir l'anonymat, à la fois par des moyens intégrés (comme dans i2p ou Retroshare) et en faisant passer tout le trafic via TOR ou VPN.

Et enfin, l'architecture logicielle (dessinée schématiquement dans l'image de l'article). Comme déjà mentionné, le premier composant du système est un plugin de navigateur qui capture le contenu avec des méta-informations. Le deuxième composant le plus important est le service p2p, qui s'exécute en arrière-plan (« backend »). Le fonctionnement du réseau ne doit évidemment pas dépendre du fonctionnement ou non du navigateur. Le troisième composant est le logiciel client - frontend. Il peut s'agir d'un service Web local (dans ce cas, l'utilisateur pourra travailler avec un réseau décentralisé sans quitter son navigateur préféré), ou d'une application GUI distincte pour un système d'exploitation spécifique (Windows, Linux, MacOS, Andriod, iOS, etc.). J'aime l'idée que toutes les options frontend existent en même temps. Dans le même temps, cela nécessitera une architecture back-end plus stricte.

Il existe de nombreux autres aspects qui ne sont pas inclus dans cet article. Connexion à la distribution des stockages de fichiers existants (c'est-à-dire lorsque vous disposez déjà de quelques téraoctets de données pompées et que vous laissez le client les analyser, obtenir des hachages, les comparer avec ce qui se trouve à l'intérieur du réseau et rejoindre la distribution, et en même temps temps obtenir des métainformations sur leurs propres fichiers - noms normaux, descriptions, notes, critiques, etc.), connexion de sources externes de métainformations (telles que la base de données Libgen), utilisation facultative de l'espace disque pour stocker le contenu crypté d'autres personnes (comme dans Freenet ), l'architecture d'intégration avec les réseaux décentralisés existants (c'est une forêt complètement sombre), l'idée de hachage multimédia (l'utilisation de hachages perceptuels spéciaux pour le contenu multimédia - images, audio et vidéo, qui vous permettront de comparer les fichiers multimédias de la même signification, différentes en taille, résolution, etc.) et bien plus encore.

Bref résumé de l'article

1. Dans les réseaux décentralisés, il n'y a pas de Google avec sa recherche et son classement - mais il existe une communauté de vraies personnes. Un réseau social avec ses mécanismes de feedback (likes, reposts...) et son graphe social (amis, communautés...) est un modèle de couche applicative idéal pour un réseau décentralisé.
2. L'idée principale que j'apporte avec cet article est la sauvegarde automatique du contenu intéressant à partir d'Internet classique lorsque vous définissez un j'aime/une republication ; cela peut être utile sans p2p, en conservant simplement une archive personnelle d'informations intéressantes
3. Ce contenu peut également remplir automatiquement le réseau décentralisé
4. Le principe de sauvegarde automatique des contenus intéressants fonctionne également avec les likes/reposts dans les réseaux les plus décentralisés

Source: habr.com