Il n’y a pas d’instances dans atproto

Traduction de There Are No Instances in atproto par Dan Abramov, 19 juin 2026. À chaque fois qu’un article sur atproto est publié sur Hacker News, quelqu’un demande dans les commentaires : « Mais où sont donc toutes les instances Bluesky ? ». Le problème, c’est qu’il n’y a pas d’instances dans atproto! La question relève d’une erreur de catégorie. Les instances sont un concept issu de Mastodon, et je voulais un lien vers un article qui explique clairement cela. Voici donc cet article. #RSS et Google Reader Je sais que le RSS est encore utilisé quelque part (les balados?!), mais on peut dire que son heure de gloire est derrière nous. Ce qui est dommage. Pendant quelques années, que certains d’entre nous se souviennent peut-être avec nostalgie comme l’âge d’or du Web, on avait l’impression que bloguer, c’était cool. Maintenant, regardez cette image, car elle va être importante : Pour rappel, vous publiez du contenu sur votre propre blogue, que vous pouvez soit héberger vous-même, soit héberger sur une plateforme de blogue populaire. Mais ensuite, le contenu de tout le monde est agrégé dans des applications comme Google Reader et Feedly, ou dans des blogues collectifs comme Monologue (RIP). Notez que l’hébergement et l’agrégation sont deux choses distinctes. Vos articles ne « vivent » pas dans une application comme Google Reader. Les applications ne sont que de simples projections de la blogosphère. Sérieusement, assurez-vous que cette idée reste gravée dans votre esprit; ça va être essentiel. #Facebook et compagnie Voici ce qu’on pourrait appeler une évolution de ce concept. On encadre le tout pour que tout le monde soit confiné dans le même espace, ce qui nous permet d’afficher des publicités et tout ça. Et puis, ne gardons qu’une seule application (on peut laisser les applications alternatives exister un certain temps, mais pas trop longtemps). C’est ça, les médias sociaux traditionnels. Oh non, voilà la centralisation! Oh non, des effets de réseau incontrôlables! Oh non, bla bla bla. Qu’est-ce qu’on fait? Il faut décentraliser tout ça d’une manière ou d’une autre. #Mastodon et ses instances Je parle de « Mastodon » ici parce que si je disais « ActivityPub » à la place, une foule de gens viendrait me dire qu’en réalité, ce que je décris, c’est la façon dont Mastodon a choisi de mettre en œuvre ActivityPub. Alors qu’ActivityPub en soi ne précise pas vraiment comment l’utiliser concrètement. Je suis sûr que tout ça est très intéressant — mais je m’éloigne du sujet. Comment décentraliser un réseau social? Construisons une version de ce que nous avons vu plus tôt, mais rendons-la auto-hébergée. Ainsi, chaque communauté pourra avoir son propre « petit Facebook » ou « petit Twitter ». Nous les appellerons des instances. Elles sont un peu comme des pays — parce que vous vivez « à l’intérieur » de l’une d’entre elles : Mais attendez, cela soulève tout un tas de questions. Comment choisir l’instance à laquelle adhérer? Peut-être faites-vous partie de plusieurs communautés qui se chevauchent. Eh bien, j’imagine que vous devrez simplement choisir les administrateurs de la communauté à qui vous faites le plus confiance pour gérer votre identité et vos données. Bon, maintenant un autre problème : que faire si mon ami se trouve sur une instance différente? Comment verra-t-il mes publications? Puisque chaque instance est en quelque sorte son propre petit Facebook, elles n’ont pas de source d’information commune. Elles doivent donc s’échanger des messages : Cette topologie de réseau pourrait vous rappeler les fiefs en guerre de la Chine ancienne. Si Alice-de-l’instance-n°1 suit Bree-de-l’instance-n°2, les deux instances concluent un accord : les publications de Bree seront transmises à l’instance n°1 afin qu’Alice puisse les voir. C’est ce qu’on appelle la « fédération ». Vous publiez sur votre instance, puis votre message est transmis aux autres instances dont les utilisateurs souhaitaient recevoir vos publications. Cette image a quelques implications intéressantes : Vous « appartenez » à votre instance. Vous n’êtes pas Alice, vous êtes Alice-de-l’instance-n°-1. C’est pourquoi votre identifiant Mastodon est littéralement yourname@someinstance.com. « D’où vous venez » est une partie immuable de votre identité. (D’une certaine manière, cela s’avère encore plus restrictif que les pays et les nationalités.) Si les administrateurs de votre instance entrent en conflit avec ceux d’une autre instance, ils peuvent choisir de « cesser la fédération » et de ne plus transférer de messages entre elles. Cela pourrait expliquer de façon surprenante pourquoi vous ne voyez plus les messages de vos amis. Si votre instance tombe en panne, votre identité cesse d’exister. Les gens qui vous suivaient suivaient vous-de-cette-instance, et non un « vous réel » platonicien et abstrait. Oh, et les flèches entre les instances évoluent en fonction de O(n²). Cela n’a peut-être pas beaucoup d’importance pour l’instant, mais cela pourrait en avoir si cette approche des réseaux sociaux devenait populaire. #atproto Maintenant, oubliez tout ça — réinitialisation complète. L’erreur s’est produite lorsque nous avons dessiné cette boîte : Effacez la case. Revenons à ceci : Nous avons un hébergement où les choses « vivent » réellement, et des applications qui agrègent à partir de celles-ci. Cela a très bien fonctionné pour les blogues, alors pourquoi cela ne fonctionnerait-il pas pour littéralement tout le reste? Comme le RSS, mais pour toutes sortes de contenu. C’est ça, atproto. #Alors, où sont toutes les instances Bluesky? Maintenant, vous le savez! Il n’y a pas d’instances dans atproto. Les instances, ce sont ces entités inspirées de Mastodon : Ce sont ces fiefs isolés, regroupant hébergement et application, qui s’échangent des données. Comparez cette image à atproto. Dans atproto, nous séparons l’hébergement de l’agrégation au niveau du réseau : Il n’y a absolument aucune instance! Il y a un hébergement que vous pouvez changer, et il y a des applications qui agrègent le contenu provenant de l’hébergement de chacun. Cela ressemble beaucoup à RSS et à Google Reader. La décentralisation d’atproto est plus riche en structure que « plusieurs copies d’une même application » : Si vous voulez changer d’hébergement, vous pouvez le faire. Je l’ai littéralement fait aujourd’hui. Mis à part trois ou quatre petits problèmes d’expérience utilisateur, tout s’est fait automatiquement. Mes données atproto se trouvent désormais sur Eurosky. Si j’étais plus audacieux, je pourrais aussi héberger toutes mes données moi-même gratuitement sur Cloudflare. Si vous voulez essayer de nouvelles applications ou en créer de nouvelles, vous pouvez le faire aussi! Jetez un coup d’œil à Tangled et Semble, qui n’ont rien à voir avec Bluesky. J’ai récemment créé ma propre application (et elle est open source). Je vous recommande d’essayer vous aussi. La décentralisation vous tient à cœur? Ici, vous avez toute latitude. Décentralisez à volonté. #Libérez-vous de la « mentalité d’instance » Vous comprenez maintenant pourquoi toutes les discussions sur les médias sociaux décentralisés déraillent à ce sujet. Les utilisateurs de Mastodon mesurent la décentralisation au nombre d’instances, car c’est la seule chose que l’on peut faire sur Mastodon. S’il n’existe qu’un seul type de « boîte », et que chaque boîte est « une application couplée à un hébergement », la seule chose que l’on peut faire est d’héberger davantage de ces boîtes et de les faire communiquer entre elles. Elles sont isolées par défaut. Dans atproto, chaque application est une projection de l’Atmosphère tout entière, tout comme Feedly et Google Reader sont des projections de la blogosphère tout entière. On « décentralise » principalement en changeant d’hébergeur et/ou en créant et en essayant de nouvelles applications. Il est possible d’exécuter plusieurs copies complètes du serveur de base de données Bluesky, mais cela n’est pas plus utile que d’exécuter plusieurs copies de Google Reader. Les gens en mettent bien en place (voir Blacksky), mais celles-ci voient le jour pour répondre aux besoins spécifiques de quelqu’un (comme une philosophie de modération différente). Il existe d’autres approches également : ce client Bluesky ne dispose d’aucune base de données dédiée et se contente d’accéder à un cache gratuit géré par la communauté regroupant les hébergements de chacun. Les infrastructures de réseau partagées comme Relays sont peu coûteuses à exploiter depuis maintenant un an. C’est pourquoi « compter les instances Bluesky » est si trompeur. Ce qui importe, c’est : Les gens migrent-ils vers des solutions d’hébergement alternatives? Les gens essaient-ils de créer de nouvelles applications? Séparer l’hébergement et les applications corrige les incitatifs défaillants tant dans les réseaux sociaux fermés que fédérés. Le couplage de l’hébergement et des applications était le péché originel, et la solution est simple. Gardons nos données à l’extérieur des applications; laissons les applications s’agréger par-dessus. Comme le RSS et Google Reader.