L'émergence de plateformes de médias sociaux contrôlées par des entreprises, motivées par des intérêts commerciaux, a considérablement érodé l'espoir initial d'une culture participative en ligne. Les technologies de l'information en réseau devraient fondamentalement démocratiser la production culturelle, mais de nos jours, ces plateformes limitent et modèlent la participation en ligne principalement à des fins lucratives - un «j'aime» n'est pas une expression de gratitude pour un contenu, mais est plutôt un outil de monétisation qui alimente des algorithmes motivés commercialement.

Les plateformes de médias sociaux alternatives construites sur des protocoles décentralisés et fédérés offrent un retour à la conception originale de la socialité en ligne. Les données sont contrôlées par l'utilisateur et sont propagées à travers des bases de données décentralisées, les interfaces sont dirigées par la communauté, la modération est une expression des préférences de la communauté, les algorithmes sont choisis par l'utilisateur et un éthos open source stimule l'innovation.

Histoire des médias sociaux décentralisés et alternatifs

Avant que le web ne devienne un hub pour le commerce, le divertissement et les interactions sociales, il était principalement un outil académique et militaire. Tim Berners-Lee avait une vision égalitaire lorsqu'il a formulé les premiers protocoles web - la conception initiale d'Internet était d'être un réseau décentralisé, où l'information pouvait circuler librement entre les nœuds sans aucun point de contrôle ou de défaillance unique.

Cependant, avec l'importance croissante du web sur le plan commercial, des plateformes centralisées, telles que les moteurs de recherche et les géants des médias sociaux, ont émergé en tant qu'acteurs dominants. Bien que ces entités aient apporté une valeur significative, elles se sont éloignées de l'éthique décentralisée initiale, ce qui a donné lieu à notre environnement web2 actuel.

La principale innovation dans la chronologie des réseaux sociaux alternatifs a été l'arrivée du concept de protocoles fédérés. Un réseau fédéré fait référence à un système où de multiples serveurs indépendants ou "nœuds" coopèrent pour former un seul réseau social, par opposition aux plates-formes centralisées où une seule organisation contrôle tous les serveurs.

Dans un système fédéré, chaque serveur exécute un logiciel compatible qui suit des protocoles partagés, leur permettant de communiquer entre eux. Un utilisateur enregistré sur un serveur peut suivre, interagir avec et partager du contenu avec des utilisateurs d'autres serveurs de manière transparente, comme s'ils étaient sur la même plateforme. Des exemples de ces protocoles incluent ActivityPub et OStatus, qui alimentent des plates-formes fédérées comme Mastodon et PeerTube.

Dans une configuration fédérée, les utilisateurs peuvent choisir le serveur en lequel ils ont confiance, migrer éventuellement vers différents serveurs ou en mettre en place un, ce qui leur donne plus d'autonomie. Le terme "Fediverse'' - un mot-valise de "fédération" et "univers" - est utilisé pour décrire un tel système. Le Fediverse a commencé avec des plateformes comme GNU social et ses prédécesseurs (StatusNet et Laconica), mais le véritable tournant a été le développement et l'adoption généralisée du protocole ActivityPub, publié comme norme recommandée par le World Wide Web Consortium (W3C) en 2018.

Au sein du web3, les réseaux sociaux fédérés sont l'état par défaut des systèmes décentralisés une fois que les données sont transférées sur la chaîne. Les blockchains agissent comme un serveur backend neutre pour le contenu stocké, avec des interfaces utilisateur indexant ce contenu et le servant directement aux utilisateurs. L'identité est gérée par des paires de clés publique-privée qui gèrent déjà les portefeuilles des utilisateurs, leur permettant d'authentifier facilement toutes les données ou le contenu qu'ils génèrent. De plus, l'utilisation de primitives onchain comme les NFT peut regrouper le contenu stocké dans les métadonnées et servir de nom de domaine ou d'identifiant décentralisé (DID).

Similaire à la façon dont fonctionne ActivityPub, les protocoles web3 cherchent à amorcer des graphiques sociaux via des relations authentifiées entre les nœuds utilisateur. Comme n'importe quel frontend peut indexer et servir ce contenu, il y a une hyper-compétition au niveau du frontend, ce qui se traduit par un paysage florissant de fonctionnalités. De plus, parce que les données sont onchain, les utilisateurs peuvent élire les algorithmes qu'ils sont à l'aise d'utiliser, et ils peuvent être incités à utiliser certains d'entre eux, recapturant ainsi la valeur de leurs données. Ceci s'ajoute à des moyens plus directs de monétiser leur contenu, offrant une expérience globale améliorée pour les créateurs qui ont été largement exclus de la monétisation, même si leur contenu est ce qui stimule la demande pour ces plateformes.

Comparaison de protocole

Pour réellement apprécier les innovations au sein des protocoles de médias sociaux décentralisés, il est nécessaire de comprendre les subtilités techniques qui les rendent possibles. Notamment, nous n'incluons pas tous les protocoles sociaux ici, mais optons plutôt pour certains des plus prévalents :

Identité / Espaces de noms

Dans le contexte des graphiques sociaux fédérés et décentralisés ou des protocoles de réseau, un "namespace" fait référence à un domaine ou un royaume sous lequel les identifiants d'utilisateur ou d'autres ressources sont uniques. Il s'agit d'une manière de distinguer les ressources ou les identités d'un domaine/serveur à un autre, en veillant à ce qu'il n'y ait pas de conflits ou d'ambiguïtés lors de l'intégration ou de la communication entre plusieurs domaines.

L'identité et les espaces de noms associés à travers les protocoles sociaux décentralisés vont de simples paires de clés (Nostr, Scuttlebutt) à des URIs pointant vers des URL HTTPS hébergeant des profils (ActivityPub) à des modèles plus complexes qui utilisent des primitives onchain comme les NFT (et plus récemment des extensions ERC-6551 telles que Lens v2).

Farcaster est un excellent exemple de ces techniques. Un compte Farcaster représente une entité distincte sur le réseau. Chaque compte dispose d’un identifiant numérique unique appelé identifiant Farcaster (« fid »). Les identités sont émises et gérées onchain à l’aide d’un contrat Ethereum appelé IdRegistry. Les utilisateurs effectuent une transaction dans l’IdRegistry pour obtenir un nouveau fid. L’adresse qui possède le fid est l’adresse de garde de l’utilisateur. L’IdRegistry garantit que les fids peuvent être transférés entre les adresses et qu’il n’y a pas deux adresses qui ont le même fid. Farcaster étend également cet espace de noms pour prendre en charge les noms ENS émis sur la chaîne ou hors chaîne. Une preuve signée doit être soumise au réseau pour revendiquer un nom d’utilisateur.

ActivityPub, d'autre part, identifie chaque utilisateur par un URI unique, généralement une URL HTTPS. Cet URI pointe vers le profil de l'utilisateur et sert d'identifiant global dans le Fediverse. Pour rendre ces URI plus conviviaux, de nombreuses plateformes ActivityPub utilisent un système appelé Webfinger. Webfinger permet aux utilisateurs d'avoir une identité comme '@'username@domain.com’.

Lens et CyberConnect gèrent plutôt les profils d'utilisateurs sous forme de NFT. Dans le cas de Lens, une adresse utilisateur détient un ProfileNFT, et il est possible pour une seule adresse de détenir plusieurs ProfileNFTs. Chaque Profile NFT encapsule l'ensemble de l'historique des activités d'un utilisateur, y compris les publications, les miroirs, les commentaires et d'autres types de contenu qu'ils ont créés. De plus, les Profile NFTs disposent d'un FollowModule, qui est essentiellement un ensemble de règles qui régissent comment différents comptes peuvent obtenir des Follow NFTs. Ces Follow NFTs servent à documenter les connexions entre les comptes et le profil principal directement onchain. Il existe également des poignées (handles) qui peuvent exister et être émis séparément des profils, et peuvent être liés et déliés d'un profil à un autre. Les poignées existent dans leurs propres espaces de noms (par exemple, lens/@alice).

Données

Les données sont sans doute la caractéristique la plus importante des réseaux décentralisés, car leur création et leur normalisation sont ce qui permet à ces systèmes de fonctionner. La technique la plus courante pour gérer les données ici est l'utilisation de formats standardisés comme JSON et d'objets de relation communs (par ex. likes, follows). Les objets de données principaux comprennent généralement :

Acteurs & Objets: Les « acteurs » (par exemple les utilisateurs ou les groupes) et les « objets » (par exemple les publications ou les messages) sont définis.

Publications : Les publications ou les commentaires sont encapsulés sous forme de "Publications," souvent liés à du contenu externe via des URL.

Contenu dans les journaux d'ajout uniquement : Des journaux où chaque entrée, qu'il s'agisse d'une publication ou d'une mise à jour, est un élément de contenu distinct, ajouté et stocké séquentiellement.

Plongeons dans quelques exemples de fonctionnement à l'aide de protocoles spécifiques.

ActivityPub utilise le format de données ActivityStreams 2.0, une structure basée sur JSON, pour représenter diverses interactions sociales telles que des publications ou des mentions J'aime. Le protocole différencie deux composants principaux : Client vers Serveur (C2S) et Serveur vers Serveur (S2S). C2S permet aux utilisateurs, via des applications clientes, d'interagir avec leurs serveurs respectifs. En revanche, S2S facilite la communication entre les serveurs, permettant la nature fédérée robuste du protocole.

Au sein d'ActivityPub, les entités sont catégorisées comme des "acteurs" (souvent des comptes d'utilisateurs ou des groupes) et des "objets" (contenu ou actions comme des publications ou des likes). Lorsqu'un acteur effectue une action sur un objet, cela crée une "activité" telle que "Créer", "Suivre" ou "Liker".

Les graphes sociaux Web3 reprennent bon nombre des idées clés d'ActivityPub mais les appliquent onchain. Lens Protocol, par exemple, introduit des "Publications", qui encapsulent une variété de contenus générés par les utilisateurs tels que des publications, des miroirs, des commentaires et d'autres formes de médias. Chaque Publication est associée à un ContentURI, dirigeant vers le contenu spécifique stocké sur un protocole décentralisé tel que IPFS ou Arweave, ou alternativement, sur un service de stockage centralisé tel que AWS S3. Cette configuration garantit que le profil d'un utilisateur et toutes les publications associées sont stockés en toute sécurité dans leur portefeuille personnel, s'éloignant ainsi de la dépendance aux bases de données centralisées.

De plus, Web3 permet une approche plus directe de la monétisation du contenu utilisateur et de l'influence par rapport au cadre Web2. Les utilisateurs peuvent facturer la création de Follow NFT, ou ils peuvent intégrer des modules de collecte avec leurs publications. Cette dernière option leur permet de recevoir des frais pour la création de NFT liés au ContentURI de leur publication. En plus de ces fonctionnalités, Lens Protocol propose une API GraphQL, servant à masquer les composants blockchain des interfaces frontend et, par conséquent, offrant une expérience plus conviviale que les tentatives précédentes de réseautage social décentralisé.

En fin de compte, bon nombre des protocoles de réseautage social décentralisés créent des structures de données en ajout seulement qui sont authentifiées par des clés d'utilisateur. Par exemple, sur CyberConnect, chaque morceau de données centrées sur l'utilisateur est représenté comme un flux de données où les mises à jour ne sont autorisées que par le propriétaire des données. Chaque mise à jour des données est ajoutée au flux de données sous la forme d'un journal d'engagement en ajout seulement et la structure de données résultante devient une structure de données liées par hachage appelée un DAG de Merkle. Les types de données incluent le contenu, les collections, les commentaires et les abonnements.

Scuttlebutt utilise également un journal d'ajout seulement. Chaque utilisateur a son propre journal où chaque nouveau message ou action est ajouté à la fin après avoir été signé par l'identité de l'utilisateur (c'est-à-dire la paire de clés Ed25519 associée). Il prend également en charge le partage de données binaires, appelées « blobs ». Il peut s'agir d'images, de vidéos ou de tout autre contenu binaire. Les blobs sont stockés séparément des journaux d'ajout seulement, mais des références (hashes) à ces blobs peuvent être incluses dans les journaux.

Pour Farcaster, les messages sont des mises à jour publiques comme la création d'un message, le suivi de quelqu'un ou l'ajout d'une photo de profil, et ces messages sont encodés en protobuf et doivent être hashés et signés par le signataire du compte. Les utilisateurs peuvent publier des messages sur des Hubs tant qu'ils disposent d'un espace de stockage suffisant. Les Hubs vérifient la validité des signataires de chaque message avant de les accepter.

Stockage

Les premières approches du stockage de données pour les protocoles décentralisés étaient largement hors chaîne, bien qu'elles rappellent le consensus en chaîne. Par exemple, Scuttlebutt utilise un réseau de commérages pair à pair, plaçant la responsabilité du stockage sur l'appareil local de l'utilisateur. Cette approche garantit la souveraineté des données, car les utilisateurs ont un contrôle complet sur leurs propres informations. Cependant, cela signifie également que la disponibilité des données dépend de l'appareil de l'utilisateur étant en ligne ou que d'autres pairs dans le réseau aient une copie des données. Au fil du temps, pour gérer l'espace de stockage, certains clients de Scuttlebutt pourraient avoir besoin de mettre en œuvre des stratégies de collecte des ordures pour élaguer les données anciennes ou moins pertinentes.

Une alternative à cette approche pair à pair se présente sous la forme de serveurs stockant des données, bien que avec une redondance par rapport aux plates-formes médiatiques traditionnelles. Matrix, par exemple, dispose de plusieurs homeservers qui stockent des copies de l'historique des salons et se synchronisent entre eux. Lorsqu'un utilisateur envoie un message (ou tout événement) dans un salon, son homeserver diffuse cet événement à d'autres homeservers participants, qui stockent ensuite et transfèrent l'événement à leurs clients connectés. De même, ActivityPub demande à chaque instance (ou serveur) du réseau de stocker ses données, généralement dans une base de données. Le choix de la base de données (relationnelle, NoSQL, etc.) dépend de la mise en œuvre spécifique du logiciel ActivityPub. Par exemple, Mastodon, une plateforme ActivityPub populaire, utilise une base de données PostgreSQL.

Des protocoles tels que Cyberconnect, Farcaster et Lens ont adopté les blockchains pour le stockage. L'utilisation du stockage on-chain garantit que les données sont immuables et vérifiables, offrant ainsi une base solide pour les applications décentralisées utilisant des mécanismes de consensus sous-jacents pour la synchronisation de l'état. Cependant, cette approche peut entraîner des défis en termes de scalabilité, car chaque donnée doit être stockée on-chain, ce qui peut potentiellement entraîner des frais de transaction élevés et des temps de récupération plus lents.

Cela a amené de nombreux protocoles sociaux web3 à expérimenter des approches hybrides qui utilisent un stockage onchain pour les actions moins fréquentes (par exemple, profils, abonnements) et un stockage hors chaîne pour les événements à haute fréquence (par exemple, likes, reposts, commentaires) ou télécharger des données par lots sur la chaîne à des intervalles fréquents avec un stockage hors chaîne utilisé comme mesure provisoire.

CyberConnect, afin de gérer efficacement les mises à jour fréquentes entre les connexions utilisateur, utilise une liste chaînée de hachage dans un magasin de données décentralisé. Lors de l'initialisation d'une connexion, un 'journal des opérations' est créé. Les changements d'état ultérieurs, comme le basculement entre le suivi et le non-suivi, sont ajoutés en tant que nouveaux nœuds à ce journal. Bien que ces mises à jour soient initialement stockées sur un serveur central, elles sont périodiquement téléversées en lot vers des plateformes de stockage décentralisées telles que Arweave ou IPFS. Pour une récupération rapide des données, les nœuds du journal des opérations sont stockés de manière centralisée. Cependant, les utilisateurs peuvent vérifier indépendamment l'intégrité des données en naviguant à travers cette liste chaînée de hachage. Même en dépendant d'un serveur central pour certaines requêtes de données, le système de CyberConnect est conçu pour être suffisamment décentralisé tout en offrant des performances élevées.

Farcaster utilise également une approche hybride : les contrats onchain sont utilisés pour des actions peu fréquentes où la cohérence et la décentralisation sont importantes. Les comptes, les noms d'utilisateur, le stockage et les clés sont gérés à l'aide d'une série de contrats Ethereum. Les systèmes offchain sont utilisés pour des actions fréquentes où la performance est critique. Les messages créés par les comptes utilisateurs sont stockés et propagés sur le réseau peer-to-peer des hubs Farcaster.

Discussion

Les protocoles sociaux décentralisés sont sur le point de révolutionner l'expérience utilisateur dans les interactions numériques. L'adoption accélérée des paires de clés publiques-privées, propulsée à la fois par la traction de web3 et comme mesure proactive contre le contenu généré par l'IA, facilitera une compréhension et une familiarité plus larges avec les primitives d'identité dans ce contexte, et la modération continue et la capture de données par les entreprises de médias sociaux de web2 pousseront ouvertement plus d'utilisateurs à chercher ailleurs. Nous prévoyons une courbe d'adoption accélérée pour ces protocoles.

Pour favoriser l’évolution de nouvelles applications, il est urgent que les développeurs de protocoles et les contributeurs open source s’aventurent au-delà des types de données de base et des objets de relation actuellement utilisés au niveau de la couche d’infrastructure. Bien que les primitives existantes encapsulent de manière adéquate les fonctionnalités des médias sociaux web2 conventionnels, il existe un immense potentiel d’expansion et d’innovation. La majorité des protocoles dont il est question ici prennent intrinsèquement en charge l’extensibilité au sein de leurs systèmes, fournissant une base solide pour les développements futurs et la contribution de l’open source.

Cependant, il est crucial de souligner l'importance de l'interopérabilité. Bien que les développeurs frontend soient capables d'augmenter la fonctionnalité de manière indépendante, le faire pourrait nuire aux avantages collectifs du système si les améliorations ne sont pas interopérables avec d'autres applications construites sur le même protocole sous-jacent. Assurer la compatibilité et l'intégration transparente entre les différentes applications est essentiel pour le succès à long terme et l'adoption des protocoles sociaux décentralisés.

Dans le domaine du stockage de données, le consensus émergent au sein des protocoles sociaux web3 penche vers une approche hybride. Compte tenu du volume élevé de contenu social et d'engagement, il est pragmatique d'allouer des actifs de grande valeur tels que l'identité et le contenu principal aux primitives on-chain, tout en reléguant un contenu à plus faible risque comme les likes et les réactions à des solutions hors chaîne. Cette approche équilibrée préserve non seulement l'intégrité et la sécurité des données cruciales, mais offre également une expérience utilisateur rappelant les plateformes de médias sociaux traditionnelles.

Avertissement：

1. Cet article est repris de [Gatemiroir]. Tous les droits d'auteur appartiennent à l'auteur original [1kx]. Si des objections sont formulées à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l’article dans d’autres langues sont effectuées par l’équipe de Gate Learn. Sauf mention contraire, il est interdit de copier, de distribuer ou de plagier les articles traduits.