Comment fonctionne le réseau social décentralisé Bluesky ?
TechFlow SélectionTechFlow Sélection
Comment fonctionne le réseau social décentralisé Bluesky ?
En comprenant atproto, nous pouvons comprendre Bluesky.
Dédié à des analyses Web3 approfondiesRédigé par : Steve Klabnik
Traduit par : Kurt Pan
L'une des raisons pour lesquelles je suis enthousiaste à propos de BlueSky est la manière dont il fonctionne. Dans cet article, j'expliquerai certains aspects de sa conception et les principes que je crois sous-tendre ces choix. Je ne fais pas partie de l'équipe de BlueSky, donc ce qui suit n'est que mon interprétation personnelle.
Commençons.
Pourquoi BlueSky existe-t-il ?
Voici ce que dit actuellement le site web de BlueSky :
Les réseaux sociaux sont trop importants pour être contrôlés par quelques rares entreprises. Nous construisons une base ouverte pour Internet social afin que nous puissions tous façonner son avenir.
C’est une vision d’ensemble.
D’accord, c’est une bonne idée, mais que signifie cela concrètement ? Pour l’instant, BlueSky est une application de microblogging similaire à Twitter et Mastodon. Comment cela s’intègre-t-il dans cette vision plus large ? Bien que BlueSky soit effectivement une application de type microblog, ce n’est pas toute l’histoire : BlueSky est la première application conçue pour démontrer la faisabilité du protocole Authenticated Transfer Protocol (abrégé en AT, ATP ou « atproto »). BlueSky est le « bâtiment », tandis qu’atproto constitue la « base ouverte pour l’Internet social ».
Un point important à noter : BlueSky est aussi une entreprise. Certains peuvent regarder avec scepticisme une entreprise affirmer : « Hé, nous construisons quelque chose de si grand qu’aucune entreprise ne peut le contrôler ! ». C’est un point de départ sain, mais selon moi, la réponse se trouve précisément dans atproto.
L’interaction entre ces deux entités est cruciale. Nous allons donc commencer par explorer atproto, puis examiner comment BlueSky est construit dessus.
Est-ce de la cryptomonnaie ?
La première chose à écarter est ceci : si vous entendez « Oh, c’est un réseau distribué appelé ‘tel protocole’ », une alarme mentale pourrait sonner : « Est-ce de la cryptomonnaie ? ».
Pas de panique, ce n’en est pas. Il utilise bien quelques technologies provenant du domaine des cryptomonnaies, mais il ne s’agit ni de blockchain, ni de DAO, ni de NFT ou tout autre concept similaire. Juste de la cryptographie, des arbres de Merkle, etc.
Aperçu d’atproto
La page de présentation d’AT décrit ainsi le protocole :
Le protocole Authenticated Transfer, ou atproto, est un protocole fédéré destiné aux applications sociales distribuées à grande échelle.
Analysons cela :
Protocole fédéré
Atproto est fédéré. Cela signifie que différentes parties du système peuvent être gérées par plusieurs acteurs indépendants qui communiquent entre eux.
Le choix du modèle fédéré est essentiel pour honorer l’engagement selon lequel « rien ne doit être contrôlé par une seule organisation ». D’autres éléments contribuent à cela, mais c’est une composante majeure.
Pour une utilisation à grande échelle
Si vous voulez pouvoir vous étendre, vous devez concevoir votre système en pensant à l’évolutivité dès le départ. Atproto fait des choix intéressants pour répartir davantage la charge sur les participants capables de la supporter, et moins sur ceux qui ne le peuvent pas. Ainsi, les applications construites sur atproto peuvent évoluer sans problème vers de très grands groupes d’utilisateurs.
Du moins, c’est l’espoir. Cette semaine, BlueSky a atteint 5 millions d’utilisateurs, avec une stabilité supérieure à celle de Twitter au début. Ce n’est pas aussi massif que certaines autres applications sociales, mais ce n’est pas négligeable non plus. Voyons comment cela se passe en pratique.
Applications sociales distribuées
Atproto est conçu pour connecter les gens, donc il se concentre sur les applications sociales. Actuellement, tout y est 100 % public : pas de messages privés ou de fonctions similaires. La raison est que mettre en œuvre des communications privées dans un système fédéré est extrêmement complexe ; l’équipe préfère faire les choses correctement plutôt que de sortir une version imparfaite accompagnée d’avertissements sérieux. Pour l’instant, mieux vaut n’utiliser le réseau que pour partager des contenus publics.
Ces applications sont « distribuées » car leur fonctionnement repose directement sur le réseau. Il n’existe pas de « serveur BlueSky », seulement des serveurs exécutant atproto qui échangent des messages entre eux — y compris les messages BlueSky et ceux provenant d’autres applications créées par des tiers.
Voilà pour l’aperçu général, mais concrètement, qu’est-ce que cela signifie ?
Dans atproto, les utilisateurs créent des enregistrements signés cryptographiquement pour prouver leur authorship. Ces enregistrements obéissent à un schéma appelé « lexicon ».
Les enregistrements sont stockés dans des dépôts appelés « repositories ». Ces dépôts fonctionnent comme des services exposés via HTTP et WebSocket, et peuvent dialoguer entre eux pour mutualiser les données. On les appelle généralement PDS (Personal Data Server). Un utilisateur peut soit héberger son propre PDS, soit utiliser celui fourni par un tiers.
On peut exploiter les données stockées sur le réseau pour construire des applications. Ces services sont appelés « application views » (vues applicatives), car ils offrent une perspective spécifique sur les informations du réseau. Cette vue est définie via le système de lexicon : créer une application revient à définir un lexicon structurant les données à traiter, puis à analyser uniquement les enregistrements conformes à ce lexicon, en ignorant les autres.
Si on s’arrêtait là, de graves problèmes d’évolutivité surgiraient. Par exemple, chaque fois que je publie un nouveau message sur BlueSky, devrais-je envoyer mon post individuellement à chaque dépôt de mes abonnés ? Ce serait extrêmement inefficace et coûteux pour les propriétaires de dépôts populaires. Pour résoudre cela, un service supplémentaire appelé « relais » a été introduit. Les relais agrègent les informations du réseau et les diffusent rapidement à grande échelle. En pratique, les vues applicatives n’interrogent pas directement les dépôts, mais les relais. Quand je poste, mon dépôt informe le relais, et les abonnés utilisent leurs vues applicatives pour filtrer la sortie du relais afin de ne voir que les publications des personnes qu’ils suivent. Cela signifie que les relais sont souvent volumineux et coûteux à maintenir, mais on peut imaginer des relais plus petits, ne diffusant que les messages d’un sous-ensemble restreint d’utilisateurs. Ils n’ont pas besoin de refléter intégralement le réseau, même si les grands relais le feront probablement.
Voici une illustration ASCII :
Tout ce que vous devez comprendre du cœur d’atproto tient en ceci : les gens créent des données, celles-ci sont partagées sur le réseau, et les applications peuvent interagir avec elles.
D’autres types de services sont en cours d’introduction, et d’autres arriveront probablement à l’avenir. Mais avant d’en parler, il faut aborder certaines convictions fondamentales pour comprendre pourquoi les choses ont été conçues ainsi.
Qu’est-ce que la « liberté d’expression et portée » ?
Puisque atproto a été spécifiquement créé pour les applications sociales, il doit non seulement permettre de connecter les gens, mais aussi de les déconnecter. La modération est une composante centrale de toute application sociale : « pas de modération » reste une stratégie de modération. BlueSky reconnaît que les préférences varient selon les individus, et que la modération à grande échelle est difficile.
Le protocole adopte donc une approche de « liberté d’expression et portée ». Tout ce que nous avons décrit jusqu’ici appartient à la couche « expression ». Elle se soucie uniquement de la duplication de votre contenu sur le réseau, sans tenir compte de sa signification sémantique. Les outils de modération appartiennent à la couche « portée » : vous acceptez toutes les expressions, mais vous fournissez des moyens de limiter la visibilité des contenus que vous ne souhaitez pas voir.
Parfois, on entend dire que BlueSky garantit une « liberté d’expression totale » ou « ne modère pas ». C’est inexact. Les outils de modération sont intégrés directement au protocole, afin de fonctionner avec tous les contenus du réseau, y compris ceux provenant d’applications non-BlueSky. De plus, cela vous permet de choisir vos propres modérateurs, évitant ainsi d’être affecté par les choix de modération d’autrui. Mais j’anticipe un peu : parlons maintenant des générateurs de flux et des systèmes d’étiquetage.
Qu’est-ce qu’un générateur de flux ?
La plupart des applications sociales ont une notion de « fil de discussion ». Dans atproto, ce concept est décomposé en un type de service distinct appelé « générateur de flux ». Un exemple typique de flux est : « Affiche-moi, par ordre chronologique inverse, les messages des personnes que je suis ». Récemment, les fils algorithmiques sont devenus populaires au point que certains utilisateurs non techniques les appellent simplement « l’algorithme ».
Un générateur de flux prend les données massives produites par les relais, puis vous présente une liste de contenus filtrés et triés selon ses propres critères. Vous pouvez ensuite partager ces fils avec d'autres utilisateurs.
Prenons un exemple concret : l’un de mes fils préférés est « Quiet Posters », qui affiche les messages des personnes qui publient rarement. Cela facilite le suivi de ceux que mon fil principal noie. Il existe aussi des fils comme « the ‘Gram », qui ne montre que les messages avec images, ou « My Bangers », qui met en avant vos publications les plus populaires.
À mes yeux, c’est l’une des fonctionnalités phares de BlueSky par rapport aux autres outils de microblogging : un choix total pour l’utilisateur. Si je veux créer mon propre algorithme, je peux le faire. Je peux facilement le partager. Si vous utilisez BlueSky, vous pouvez accéder à ces fils et les suivre.
Les générateurs de flux sont une nouveauté récente dans atproto. Bien qu’ils existent déjà, certaines fonctionnalités peuvent encore être incomplètes, et des changements sont possibles à l’avenir. Attendons de voir. Personnellement, ils fonctionnent bien, même si je n’ai pas encore examiné les détails techniques bas niveau.
Qu’est-ce qu’un système d’étiquetage (« labeler ») ?
Un système d’étiquetage est un service qui applique des étiquettes à des contenus ou des comptes. En tant qu’utilisateur, vous pouvez vous abonner à un étiqueteur particulier, modifiant ainsi votre expérience en fonction des étiquettes présentes sur les messages.
L’étiqueteur peut utiliser n’importe quelle méthode : algorithmes automatiques analysant les messages, votes manuels positifs ou négatifs par une communauté, ou toute autre approche choisie par son opérateur.
Un exemple d’étiquetage est la liste noire : marquer les messages d’utilisateurs dont vous ne souhaitez pas voir le contenu. Un autre exemple est un filtre « non adapté au travail », qui pourrait analyser les images jointes aux messages et les étiqueter si elles semblent inappropriées.
Les étiqueteurs existent déjà, mais je ne crois pas qu’il soit actuellement possible d’en lancer un soi-même. BlueSky en exécute un, mais à ma connaissance, aucune version externe n’est disponible. Une fois que ce sera possible, on pourra imaginer des communautés lançant leurs propres services, ajoutant les types d’étiquettes qu’elles souhaitent.
Comment fonctionne la modération dans atproto ?
En combinant ces éléments, voici comment la modération fonctionne : les générateurs de flux peuvent transformer les fils en fonction des étiquettes, ou les vues applicatives peuvent interroger les étiqueteurs pour adapter les flux. Ces mécanismes peuvent être combinés librement selon les préférences.
Cela signifie que vous pouvez choisir votre expérience de modération non seulement entre applications, mais aussi à l’intérieur d’une même application. Vous voulez un fil adapté au travail, mais autoriser du contenu inadapté dans un autre ? Vous pouvez. Vous voulez créer une liste noire et la partager avec le monde ? Vous pouvez.
Puisque ces outils de modération agissent au niveau du réseau et non de l’application, ils vont plus loin que d’autres systèmes. Si quelqu’un construit un clone d’Instagram sur atproto, vous pourrez quand même utiliser votre étiqueteur de blocage, car il fonctionne au niveau du protocole. Bloquez quelqu’un à un endroit, et s’il le faut, il sera bloqué partout. Peut-être que dans différentes applications, vous choisirez différentes politiques de modération. C’est 100 % à vous de décider.
Ce modèle diffère fortement des autres systèmes fédérés, car vous n’avez pas réellement un « compte » sur une « instance » comme dans Mastodon. Beaucoup demandent donc : « Que se passe-t-il si mon instance est dés-fédérée ? », mais cette question n’a pas tout à fait de sens ici. Vous pouvez atteindre un résultat similaire en bloquant un groupe d’utilisateurs selon certains critères — par exemple, si vous n’aimez pas un PDS donné, vous pouvez ignorer les messages venant de ce PDS. Mais c’est un choix personnel, uniquement le vôtre, et non décidé par un « propriétaire de serveur » où votre compte serait hébergé.
Mais alors, comment fonctionne l’identité si vous n’avez pas de serveur personnel ?
Comment fonctionnent l’identité et la portabilité des comptes ?
Il y a beaucoup de détails sur le fonctionnement de l’identité, donc je me concentrerai sur ce que je considère comme essentiel. J’insisterai aussi sur les aspects controversés, car ils sont importants.
Au cœur du système, chaque utilisateur possède un identifiant appelé « DID » (Decentralized Identifier). Mon DID ressemble à ceci : did:plc:3danwc67lo7obz2fmdg6jxcr. Suivez-moi ! Bien sûr, ce n’est pas l’interface que vous voyez habituellement. L’identité inclut aussi un « handle », un nom de domaine. Comme prévu, mon handle est steveklabnik.com. Vous verrez mes messages sur BlueSky provenir de @steveklabnik.com. Le système fonctionne aussi pour ceux qui n’ont pas de domaine : si vous vous inscrivez à BlueSky, vous pouvez choisir un nom, et votre handle deviendra @username.bsky.social. J’ai commencé avec @steveklabnik.bsky.social, puis migré vers @steveklabnik.com. Mais comme le DID est stable, mes abonnés n’ont pas été affectés — ils ont juste vu le handle mis à jour dans l’interface.
Vous pouvez utiliser un domaine comme handle en récupérant le DID généré par votre PDS, puis en ajoutant un enregistrement TXT dans le DNS de votre domaine. Si vous n’êtes pas à l’aise avec le DNS (ou ne savez même pas ce que c’est), je vous envie, mais vous pouvez quand même utiliser le partenariat entre BlueSky et NameCheap pour enregistrer un domaine et le configurer comme handle sans aucune compétence technique. Ensuite, vous pouvez vous connecter aux applications avec votre domaine, et tout fonctionnera normalement.
C’est aussi ainsi que BlueSky offre une véritable « portabilité des comptes », en partie parce qu’il n’y a en réalité aucun concept de « compte ». La personne utilisant un DID donné signe cryptographiquement ses contenus, qui sont ensuite répliqués sur le réseau. Votre « compte » ne peut pas vraiment être banni, car cela impliquerait d’empêcher l’utilisation d’une clé à laquelle personne n’a accès. Si votre PDS tombe en panne et que vous voulez migrer vers un nouveau, il existe une méthode pour restaurer tout le contenu depuis le réseau lui-même, et informer le réseau du changement d’hébergement. C’est une portabilité réelle et significative, radicalement différente de tout service similaire aujourd’hui.
Mais.
Le diable se cache dans les détails, et je pense que c’est l’une des critiques les plus pertinentes adressées à BlueSky et atproto.
Vous voyez, il existe plusieurs « méthodes » pour créer un DID. BlueSky en supporte deux : did:web, basé sur les domaines. Cette méthode présente certains inconvénients que je ne comprends pas encore pleinement, donc je ne peux pas les décrire ici. J’espère écrire prochainement un article approfondi sur les DID.
À cause de ces faiblesses, BlueSky a développé sa propre méthode, appelée did:plc. PLC signifie « placeholder », car malgré l’intention de la soutenir indéfiniment, elle comporte aussi des limites. Le problème est qu’elle nécessite d’interroger un service géré par BlueSky pour résoudre les bonnes informations. Par exemple, voici ma requête. Cela signifie que BlueSky pourrait vous bannir de manière plus sévère que ce que la conception du réseau rend normalement impossible, ce que certains jugent très grave.
Alors, ce défaut est-il fatal ? Pas selon moi. Premièrement, si vous ne voulez vraiment pas y participer, vous pouvez utiliser did:web. Oui, ce n’est pas parfait non plus pour d’autres raisons — après tout, c’est pour cela que did:plc a été créé. Mais vous pouvez contourner le problème.
Deuxièmement, selon moi, l’équipe de BlueSky a montré suffisamment de transparence et d’inconfort face à ce contrôle centralisé. Le système est conçu de manière à permettre la migration vers de meilleurs systèmes si jamais ils apparaissent. Ils ont aussi indiqué qu’une gouvernance décentralisée de did:plc via un modèle de consensus pourrait être envisagée à l’avenir. Des alternatives existent. D’ailleurs, d’autres peuvent lancer leurs propres services did:plc et les utiliser s’ils le souhaitent.
Je pense personnellement que c’est un exemple de pragmatisme, tandis que d’autres y voient un complot machiavélique. À vous de juger.
Comment BlueSky est-il construit sur atproto ?
Maintenant que nous comprenons atproto, nous pouvons comprendre BlueSky. BlueSky est une application construite au-dessus du réseau atproto. L’équipe exploite une vue applicative, ainsi qu’une application web qui utilise cette vue. Elle gère aussi un PDS pour les utilisateurs s’inscrivant via l’application web, ainsi qu’un relais communiquant avec ces PDS.
Elle a publié deux lexicons : un pour com.atproto.* et un autre pour app.bsky.*. Le premier couvre les opérations élémentaires nécessaires à toute application du réseau, tandis que le second concerne les fonctionnalités spécifiques à BlueSky.
Mais un excellent aspect de BlueSky est que son objectif produit est que personne n’ait besoin de connaître tous ces détails techniques pour l’utiliser. L’absence d’instances signifie qu’il n’y a pas de processus du type « je dois choisir une instance pour créer un compte », et la portabilité implique que si mon hébergeur tombe en panne, je peux migrer sans que mes abonnés ne s’en rendent compte.
Comment d’autres peuvent-ils construire des applications sur atproto ?
Vous pouvez créer une application atproto en définissant un lexicon. Ensuite, vous devez lancer une vue applicative pour traiter les données du réseau correspondant à votre lexicon, et votre application permettra aux utilisateurs d’écrire des données dans leur PDS selon ce lexicon.
J’y réfléchis moi-même. Voyons ce que ça donne.
Conclusion
Voilà, sur le plan technique, c’est un aperçu du fonctionnement d’atproto et de BlueSky. Je trouve cette conception très ingénieuse. En outre, je pense qu’il est très utile de distinguer atproto et BlueSky, car la présence d’une « application phare » donne une raison concrète d’utiliser le réseau. C’est aussi une forme de test, garantissant qu’atproto est assez solide pour construire de véritables applications.
Je suis sûr que j’aurai encore beaucoup à dire sur tout cela à l’avenir.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
