Bluesky est-il décentralisé ?

Décentralisation quantique

Bluesky est-il décentralisé ?

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.

Le 21 novembre à 16h34

Commentaires (8)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Betterige a encore frappé !
fr.wikipedia.org Wikipedia

ça lie très bien avec l'article d'hier où les commentaires mettaient le côté supposé fédéré et décentralisé de Bluesky en avant
Merci Vincent!
votre avatar
Haha bien vu pour Betterige ;-)

C'est précisément la conversation, très riche, enclenchée entre hier et ce matin qui nous a motivé à synthétiser les choses et essayer de les rendre accessibles au plus grand nombre !

C'est aussi le fait qu'on lit partout que BS est un réseau "décentralisé", alors que comme le montre Vincent, c'est un peu plus compliqué que ça...

D'ailleurs @Vincent_H on aura peut-être intérêt à faire un article du même genre sur ActivityPub, histoire de :santa_flock:
votre avatar
:prison:
votre avatar
On veut la version ActivityPub ! <3

Merci @VincentHermann pour l'article !
votre avatar
Threads, nous dit-on, serait compatible avec ActivityPub, voire serait une instance parmi les autres ? Instance encore plus énorme que mastodon.social ?
votre avatar
Je pense que ça doit être plus une couche de compatibilité dans le cas de Threads qu'autre chose. Meta a quand même une très forte expérience sur le fonctionnement des médias sociaux et les enjeux techniques, il serait con de reposer sur un protocole tiers alors qu'ils ont très certainement tout ce qu'il leur faut à la maison avec des années de développement et perfectionnement.

Donc je vois plus son intégration ActivityPub comme un moyen d'interco pour se connecter au Fediverse que comme un backend pur. Un peu comme les bus d'événement chez les Cloud Provider par exemple, qui ont tous une compatibilité Apache Kafka / Kafka Connect (car produit très à la mode dans le domaine) mais qui reposent sur un logiciel propriétaire du CSP.

Cette couche de compatibilité est, évidemment, un moyen de faciliter la migration d'une solution à l'autre. On le voit aussi dans le domaine des SDK autour de l'IA générative où les autres concurrents émulent les API d'OpenAI dans les leurs. Celles-ci sont devenues un standard de fait en raison de la rapide adoption de leurs produits. C'est aussi utilisé dans la stratégie du EEE comme l'a subi XMPP en son temps.
votre avatar
Merci pour ce récap, c'est intéressant.

Je pense qu'il y a dans tous les cas une idée fondamentalement différente entre ActivityPub utilisé par Mastodon (entre autres) et AT Protocol de Bluesky.

La fédération et la décentralisation ont, à mon sens, quelques petites subtilités.

ActivityPub, techniquement, c'est comme un email : des messages (événements) placés dans des boites in et out. Il est vraiment abstrait de l'application qui l'implémente. C'est là où la fédération diffère un peu de la décentralisation, car ça signifie qu'on interconnecte une multitude de produits différents via un protocol commun (Mastodon, PeerTube, PixelFed, etc, utilisent ActivityPub alors que ce sont des logiciels différents). Un peu comme HTTP sert à faire causer plein de technos et produits différents. La fédération n'est pas une nécessité en soi et une instance Mastodon peut vivre de manière isolée (réseau social interne d'entreprise par exemple).

L'idée du décentralisé à la Bluesky, je la vois au sens où on a un service (ici : un média social) mais dont on peut instancier soi-même certains composants pour rejoindre une ruche collective qui elle, est centralisée. De ma compréhension de l'explication du protocole AT et de son implem de Bluesky, c'est grosso merdo comme du Bittorrent où le tracker (une partie centralisée, mais potentiellement multiple) s'occupe de la mise en relation avec les Peers (qui seraient un mix du PDS et Relay je dirais de prime abord). La diff avec la fédération, c'est qu'ici, le produit décentralisé n'est pas autonome, car il lui manque l'annuaire central. Mais comme ce produit décentralisé est rattaché à un service (ce que n'est pas Mastodon, par exemple), c'est une architecture qui s'explique aussi.
votre avatar
Petite remarque quand même, mais qui a son importance. L’usage d’un relay n’est PAS obligatoire.
Il est utilisé pour des questions de performance, mais le protocole est prévu pour fonctionner sans, et c’est officiellement dans la doc, et AT encourage officiellement à s’en passer.

https://atproto.com/guides/glossary#relay
Relays are an optimization and are not strictly necessary. An AppView could communicate directly with PDSes (in fact, this is encouraged if needed). The Relay serves to reduce the number of connections that are needed in the network.

docs.bsky.app Bluesky
Given all that, our proposed methodology here of networking through Relays instead of server-to-server isn’t prescriptive. The protocol is actually explicitly designed to work both ways.

Donc absolument aucun problème à ce qu’actuellement seul BS en fasse tourner un ou que ça ne soit à la portée que de gros moyens.

Et dire « sans relay, rien ne fonctionne » est donc faux.

Bluesky est-il décentralisé ?

  • Un serveur, un relai et une vue entrent dans un bar

  • Que peut-on faire soi-même ?

  • Bluesky n’est ni fédéré, ni décentralisé… pour l’instant

Fermer