Décentralisation quantique
Bluesky et son protocole AT sont souvent décrits comme décentralisés, à la manière de Mastodon. Mais est-ce bien le cas ? La question fait débat.
Bluesky est actuellement sous les feux des projecteurs. L’effet boule de neige semble enclenché et on peut voir un nombre croissant de comptes importants partir de X pour des cieux plus cléments. Chez Science, on lit la même chose au sujet de la communauté scientifique.
Bluesky attire pour plusieurs raisons, en plus du critère classique de nouvel horizon. D’une part, des fonctions de blocage et de modération nettes et précises. D’autre part, l’affichage chronologique par défaut des publications, loin des algorithmes poussant à l’engagement. Et que cet engagement se fasse sur les impressions de publicités ou sur les réactions de comptes Premium n’y change rien.
Que sait-on de Bluesky ? C’était initialement un projet incubé chez Twitter par Jack Dorsey en personne. Le fondateur de Twitter souhaitait tester l’idée d’un protocole open source pour un réseau de micro-blogging. Cette idée a accouché du protocole AT, qui est effectivement open source, sous double licence Apache 2.0 et MIT. Jack Dorsey, lui, a quitté l’entreprise en mai.
Ce protocole a été pensé initialement pour permettre un fonctionnement décentralisé et fédéré, comme le propose Mastodon. Mais peut-on dire que Bluesky est réellement décentralisé ? La réponse n’est pas si simple.
Un serveur, un relai et une vue entrent dans un bar
Lorsque l’on parle de Bluesky, on évoque le réseau dans son intégralité. Mais ce réseau se compose en fait de trois parties, comme l’entreprise l’explique dans sa documentation : les serveurs, les relais et les vues d’applications.
Les serveurs constituent les réservoirs de données personnelles. Un utilisateur peut y stocker toutes ses informations, dont ses publications et tout ce qui sert à l’identifier (nom de connexion, mots de passe, clés cryptographiques) ou encore la liste des personnes suivies. Les PDS (Personal Data Server) gèrent également la mise en relation avec les services en fonction des requêtes. Il peut y avoir autant de PDS que l’on souhaite et tout le monde peut en créer un. En théorie.
Sur les relais en revanche, tout change. Leur mission est de parcourir tous les PDS, d’agréger et indexer le contenu pour en produire un énorme flux unique de données en streaming, souvent appelé firehose dans le jargon. Ce flux est ensuite mis à disposition de tout l’écosystème atproto (protocole AT). Les relais agissent comme un moteur de recherche.
Quant aux vues d’application (App View), elles constituent la face visible de l’iceberg. Une App View est ce qui permet d’afficher des informations exploitables à partir du flux agrégé. Elle réalise un assemblage à partir des critères définis aussi bien par la requête que les différents paramètres. Par exemple, afficher le flux personnel ou les résultats d’une recherche, tout en masquant certains résultats, par exemple provenant des personnes bloquées.
Que peut-on faire soi-même ?
Certaines actions peuvent être entreprises par les utilisateurs, du moins sur le papier. Monter un serveur personnel est le plus simple, Bluesky fournissant de nombreuses informations sur GitHub et jusqu’à un conteneur pour simplifier l’installation. Mais, comme son nom l’indique, un serveur de données personnelles ne peut héberger que ses propres informations. Il n’est pas question de créer une instance comme le fait Mastodon. On ne peut y inviter personne.
Sur les relais, c’est nettement plus compliqué. Dans sa documentation, Bluesky explique que tout le monde peut en héberger un, mais que c’est « un service assez gourmand en ressources ». Gourmand comment ? Très vorace en fait, car les relais arpentent l’intégralité des PDS pour en indexer le contenu. Certaines estimations tablent sur un minimum de 4,5 To à l’installation et d’une croissance minimale de 18 Go par jour pour les seules données JSON, sans parler des données brutes, beaucoup plus volumineuses, d’un facteur 10 selon Gavin Anderegg. Ce dernier rappelle d’ailleurs que ces chiffres ne tiennent pas compte du récent emballement dans les inscriptions sur Bluesky.
Concernant les vues d’applications, techniquement tout le monde peut en développer. Dans l’idée d’ailleurs, Bluesky parle de vue pour évoquer un prisme permettant de représenter des données depuis un flux brut. Si la seule utilisation actuelle est faite dans le cadre d’un service de micro-blogging, le protocole AT peut a priori être utilisé pour tout et n’importe quoi.
Pour le reste, tout est du ressort strict de l’entreprise. Bluesky contrôle notamment deux éléments importants : les DID:PLC et les DM. Les premiers représentent, dans les grandes lignes, les identifiants des utilisateurs. Les seconds sont les messages privés, qui ne sont pas pris en charge par le protocole AT. Les données correspondantes ne sont donc pas présentes dans les PDS, mais gérées directement par Bluesky de manière séparée.
Bluesky n’est ni fédéré, ni décentralisé… pour l’instant
Le protocole AT a été pensé pour être décentralisé. Dans la pratique, Bluesky ne l’est pas. La possibilité de créer facilement un PDS n’est qu’un petit élément parmi d’autres. Même si l’on peut créer des relais, leur mise en œuvre est complexe et sans doute bien trop onéreuse en stockage et bande passante pour être intéressante.
On ne peut pas dire que Bluesky soit actuellement décentralisé, et encore moins fédéré. Il y a bien un centre, et il est géré par l’entreprise Bluesky. Sans son relai, rien ne fonctionne. Chaque serveur de données personnelles ne sert ainsi que comme petit réservoir pour les informations d’une personne, incapable de fonctionner par lui-même.
Pour Gavin Anderegg, ce n’est ni bien ni mauvais : ce n’est que le fonctionnement actuel, qui pourrait changer. Il estime en effet que l’équipe en charge du réseau se dirige petit à petit vers la décentralisation, mais que la tâche reste immense au vu des choix techniques. En outre, il souligne la grande ouverture du protocole, qui permet de voir l’intégralité du flux, puisque toutes les informations y sont publiques.
Cet aspect du réseau est d’ailleurs moins connu et peut avoir toute son importance : rien de ce que vous publiez sur Bluesky n’est privé. On peut s’en rendre compte facilement en allant dans les options de vie privée et sécurité. Là, un réglage propose de masquer le compte aux personnes non connectées à Bluesky. Cependant, on est averti : « Bluesky est un réseau ouvert et public. Ce paramètre limite uniquement la visibilité de votre contenu sur l’application et le site Web de Bluesky, et d’autres applications peuvent ne pas respecter ce paramètre. Votre contenu peut toujours être montré aux personnes non connectées par d’autres applications et sites Web ». Les profils privés n’existent pas sur le réseau. Une page résume la situation sur les données publiques et privées.
Connexion
