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 (11)

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
Threads est compatible mais il demande que l'instance avec laquelle il s'interconnecte publie publiquement son contenu.
Par exemple, mon instance est configurée par défaut en privé. Si mes membres veulent avoir un compte public, ça nécessite une action de leur part et c'est tout l'intérêt. Ils et elles doivent être conscient que c'est un choix important.

Je ne suis, donc, pas compatible avec Threads et c'est de la merde, en gros.

Attention, une instance privée ne veut pas dire que les publications ne sont pas visible de l'extérieur. On discute avec la terre entière sans souci. Ça veut juste dire que, sans compte, tu ne peux pas tout voir de l'extérieur.
votre avatar
Voilà y a ça, d'une part et puis y a la méthode.

Une vue un peu biaisée d'un hébergeur d'une instance Mastodon de 2 utilisateurs: Y a quelques mois (un peu plus d'un an en fait), Meta a invité "confidentiellement" les administrateurs.ices des "grosses" instances Mastodon à causer fédération. Il s'en est suivi un débat ouvert, pas du tout confidentiel, autour de "oui/non pourquoi/comment avec quelles conséquences" on pourrait accepter de fédérer avec les serveurs de Threads.

Un article ici par exemple : https://hub.fosstodon.org/facebook-fosstodon-fedi

De nombreuses instances (invitées ou pas par Méta) on eu cette conversation en interne et ont conclu selon les cas "on bloque les serveurs méta" ou "on va bien voir" ou "mais si allons-y, fédérons". (blocage préventif puisque la fédération n'était encore qu'en projet et pas du tout effective à ce moment là).

Dans la première catégorie y a celleux qui savent bien comment marchent les machines à emmerdification comme Facebook et qui ont bien compris qu'il ne s'agit là que d'une nouvelle mouture du Embrace Extend Extinguish d’antan. (les barbus des années 90 reconnaîtront).

Dans la dernière catégorie, y a Mastodon.social, l'instance de Eugene. et la direction qu'il prend (pousser son instance promotionnellement au détriment des autres) est pas super bien perçue. J'ai plus les chiffres du moment mais je serais pas étonné que mastodon.social représente 1/4 ou plus des utilisateurs.ices actifs de Mastodon. Alors que initialement, l'objectif était justement de pousser à des myriades de petites instances à taille humaine. Et donc mastodon.social ne s'oppose pas à threads et n'a pas il me semble une attitude hostile envers Meta. (normalement y a le meme de Gandalf "Fly you fools" qui arrive à ce moment là).

A titre perso, sur mon instance de 2, j'ai bloqué Threads.
votre avatar
Bluesky c'est c'est comme twitter et game of thrones, plus on en parlera, moins j'aurais envie d'y aller.
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