Un aperçu du protocole AT de BlueSky m'a aidé à comprendre pourquoi il doit exister

En 2022, Elon Musk a racheté Twitter, qui a depuis été rebaptisé X. Cette partie de l’histoire est largement connue. Cependant, moins de gens savent qu’un projet de décentralisation de la plateforme prenait forme au sein de Twitter. Ce projet, baptisé BlueSky , a été lancé en 2019. En 2021, il a été transformé en Bluesky Social Benefit Corporation, ce qui lui a permis de continuer à fonctionner indépendamment de Twitter. À certains égards, BlueSky peut être considéré comme le successeur de Twitter au même titre que X.

X est un service à but lucratif, proposant une validation payante et des fonctionnalités premium. En revanche, BlueSky est un système entièrement ouvert construit sur des protocoles ouverts similaires à Fediverse , constitué d'une multitude de nœuds indépendants.

Comme l'équipe BlueSky n'était pas satisfaite de la norme ActivityPub , elle a développé son propre protocole, appelé protocole AT .

L'élément central du protocole est le référentiel, qui est similaire à une base de données. C'est là que les publications, les mentions « j'aime » et toutes les autres données sont stockées. Chaque utilisateur (ou toute entité) dispose d'un référentiel. Le référentiel contient des collections (similaires aux tables de base de données), et les collections contiennent des enregistrements dans un format clé-valeur. Le référentiel stocke les données comme IPFS . Chaque enregistrement possède un CID , qui est un hachage basé sur le contenu. Si un utilisateur modifie quelque chose dans la base de données, un hachage de validation est généré à partir des données (similaire à une validation Git). Même une modification d'un seul bit dans la base de données entraîne un nouveau hachage de validation. Le propriétaire du référentiel signe numériquement ce hachage de validation après chaque modification, authentifiant ainsi la base de données.

L’avantage de cette solution est que l’ensemble du référentiel ou ses parties peuvent être librement transférés entre les systèmes tout en conservant la capacité pour tout système de vérifier facilement l’authenticité des données.

Les utilisateurs peuvent héberger leur référentiel sur un serveur de données personnelles (PDS) de leur choix. En ce sens, le PDS fonctionne comme un serveur de base de données. Grâce au PDS, les utilisateurs peuvent modifier leur référentiel et le rendre accessible à d'autres. Au-delà de cela, le PDS fournit une large gamme de services supplémentaires. Il permet d'accéder aux données d'autres utilisateurs, de récupérer des flux, etc. Essentiellement, le PDS sert de nœud de médias sociaux entièrement fonctionnel, permettant aux utilisateurs de se connecter au réseau.

Le PDS n'étant que le système qui gère le référentiel, les utilisateurs ont la liberté de déplacer leur référentiel entre différents PDS ou même d'exploiter leur propre PDS. C'est cette flexibilité qui confère au système sa liberté.

Le contenu des référentiels stockés sur les PDS est surveillé par des générateurs de flux, qui créent des flux en fonction de critères spécifiques. Sur d'autres plateformes de médias sociaux (par exemple Facebook), il n'y a généralement qu'un seul flux, mais dans le cas de BlueSky, les utilisateurs sont libres de choisir le flux dont ils veulent voir les publications. Si un utilisateur estime qu'un générateur de flux n'affiche pas les publications pertinentes pour ses intérêts, censure les publications qu'il souhaite voir ou tente de les manipuler, il peut simplement passer à un autre fournisseur de flux.

Ce réseau de systèmes souple et la facilité de transfert des référentiels offrent une liberté totale sans sacrifier l'efficacité. Par exemple, le client n'a pas besoin de collecter des messages provenant de plusieurs sources, car cette tâche est gérée par le générateur de flux et le PDS.

Maintenant que nous comprenons la structure du système et ses principaux composants, plongeons un peu plus profondément et voyons comment fonctionne le protocole.

Chaque utilisateur (et autres entités) se voit attribuer un identifiant décentralisé unique (DID) . Ce DID est associé au référentiel et à la paire de clés utilisée par l'utilisateur pour signer les validations du référentiel. Les DID étant difficiles à mémoriser, les utilisateurs sont identifiés par des noms de domaine, que le système traduit en DID.

Par exemple, mon nom d'utilisateur est thebojda.bsky.social . Le DID peut être lié à celui-ci de deux manières : soit en le spécifiant dans l'enregistrement TXT du domaine avec la clé appropriée, soit simplement via l'URI bien connue. Le DID est accessible à cette URL :

 https://thebojda.bsky.social/.well-known/atproto-did

Par exemple, mon DID est : did:plc:4x7rynvskplz54p5pofj3jxa

Le protocole AT prend en charge les types de DID PLC et Web . Un DID Web est une simple URL, tandis que le DID PLC est une norme personnalisée du protocole AT, générée à partir de la clé publique et de certaines données supplémentaires (ceux qui sont intéressés par une analyse plus approfondie peuvent en savoir plus ici ).

Chaque DID est associé à un document DID, qui contient la clé publique liée au DID et l'URL du PDS où le référentiel est hébergé.

Un DID peut être résolu comme ceci :

 https://plc.directory/did:plc:4x7rynvskplz54p5pofj3jxa

Le document DID ressemble à ceci :

 { "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/multikey/v1", "https://w3id.org/security/suites/secp256k1-2019/v1" ], "id": "did:plc:4x7rynvskplz54p5pofj3jxa", "alsoKnownAs": [ "at://thebojda.bsky.social" ], "verificationMethod": [ { "id": "did:plc:4x7rynvskplz54p5pofj3jxa#atproto", "type": "Multikey", "controller": "did:plc:4x7rynvskplz54p5pofj3jxa", "publicKeyMultibase": "zQ3shaNKzE66K1Kr3dmbnDwXWHh6v4nUcBmpEaK7bVktKTwfh" } ], "service": [ { "id": "#atproto_pds", "type": "AtprotoPersonalDataServer", "serviceEndpoint": "https://fibercap.us-west.host.bsky.network" } ] }

Dans ce document, l'URL du PDS doit être mise à jour si quelqu'un passe à un nouveau PDS. Par exemple, mon PDS actuel est accessible à l'adresse https://fibercap.us-west.host.bsky.network .

La communication avec le PDS se fait via XRPC , un protocole simple basé sur HTTP/JSON. Chaque appel a un nom de type DNS inversé. Par exemple, si je veux récupérer l'intégralité de mon référentiel, je peux le faire comme ceci :

 https://fibercap.us-west.host.bsky.network/xrpc/com.atproto.sync.getRepo?did=did:plc:4x7rynvskplz54p5pofj3jxa

La méthode com.atproto.sync.getRepo est utilisée pour interroger le référentiel et possède un paramètre did .

L'équipe BlueSky a développé un langage descriptif basé sur JSON appelé Lexicon pour définir l'API et les structures de données. Il est similaire à JSON Schema et peut être utilisé pour générer des interfaces de type sécurisé, par exemple pour TypeScript, ce qui simplifie l'implémentation du protocole.

L'appel suivant peut être utilisé pour récupérer mes 10 derniers messages :

 https://public.api.bsky.app/xrpc/app.bsky.feed.getAuthorFeed?actor=thebojda.bsky.social&limit=10

Le résultat ressemble à ceci :

 { "feed": [ { "post": { "uri": "at://did:plc:4x7rynvskplz54p5pofj3jxa/app.bsky.feed.post/3le3esbhaek2l", "cid": "bafyreihagjnwrkakkajkaighz6kyqww3wznvbdcqpnl4wbfnpwrr2xwmmi", "author": { "did": "did:plc:4x7rynvskplz54p5pofj3jxa", "handle": "thebojda.bsky.social", "displayName": "Laszlo Fazekas", "avatar": "https://cdn.bsky.app/img/avatar/plain/did:plc:4x7rynvskplz54p5pofj3jxa/bafkreibxd4mx7rehgkc77diautavpcota6jotzkaagp4zv2t6w3a52n7sq@jpeg", "labels": [], "createdAt": "2024-11-24T01:36:39.146Z" }, "record": { "$type": "app.bsky.feed.post", "createdAt": "2024-12-24T21:20:56.891Z", "embed": { "$type": "app.bsky.embed.external", "external": { "description": "MyETHMeta is a decentralized metadata service for Ethereum accounts. It is something like Gravatar. There are no backend servers, you fully own your data.", "thumb": { "$type": "blob", "ref": { "$link": "bafkreifoezhkdtesuhkaoqt3yml44geozu6ckg2cfffg5t5omob2bdjmo4" }, "mimeType": "image/jpeg", "size": 669185 }, "title": "MyETHMeta v2 – Some Improvements on the Gravatar for Your Ethereum Account | HackerNoon", "uri": "https://hackernoon.com/myethmeta-v2-some-improvements-on-the-gravatar-for-your-ethereum-account" } }, "facets": [ { "features": [ { "$type": "app.bsky.richtext.facet#link", "uri": "https://hackernoon.com/myethmeta-v2-some-improvements-on-the-gravatar-for-your-ethereum-account" } ], "index": { "byteEnd": 270, "byteStart": 240 } } ], "langs": [ "en" ], "reply": { "parent": { "cid": "bafyreieipk3kgwonq3h62wyadauplzgcpdgcg6pxp2776oeldcstgybwha", "uri": "at://did:plc:4x7rynvskplz54p5pofj3jxa/app.bsky.feed.post/3le3es7kzmc2l" }, "root": { "cid": "bafyreieipk3kgwonq3h62wyadauplzgcpdgcg6pxp2776oeldcstgybwha", "uri": "at://did:plc:4x7rynvskplz54p5pofj3jxa/app.bsky.feed.post/3le3es7kzmc2l" } }, "text": "MyETHMeta is a decentralized metadata service for Ethereum accounts. It is something like Gravatar, but here the metadata and your profile picture is assigned to your Ethereum address. There are no backend servers, you fully own your data. hackernoon.com/myethmeta-v2..." }, "embed": { "$type": "app.bsky.embed.external#view", "external": { "uri": "https://hackernoon.com/myethmeta-v2-some-improvements-on-the-gravatar-for-your-ethereum-account", "title": "MyETHMeta v2 – Some Improvements on the Gravatar for Your Ethereum Account | HackerNoon", "description": "MyETHMeta is a decentralized metadata service for Ethereum accounts. It is something like Gravatar. There are no backend servers, you fully own your data.", "thumb": "https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:4x7rynvskplz54p5pofj3jxa/bafkreifoezhkdtesuhkaoqt3yml44geozu6ckg2cfffg5t5omob2bdjmo4@jpeg" } }, "replyCount": 0, "repostCount": 0, "likeCount": 0, "quoteCount": 0, "indexedAt": "2024-12-24T21:21:02.466Z", "labels": [] }, "reply": {} }, {}, {}, {}, {}, {}, {}, {}, {} ] }

Chaque élément contient un message et ses réponses associées. Comme mentionné précédemment, chaque message est un enregistrement dans le référentiel et possède son propre identifiant unique. Chaque message peut se voir attribuer un URI unique, qui se compose du DID, du nom de la collection et de l'ID du message. Dans l'exemple ci-dessus, l'URI ressemble à ceci : at://did:plc:4x7rynvskplz54p5pofj3jxa/app.bsky.feed.post/3le3esbhaek2l

Cela signifie que la publication est située dans le référentiel associé à mon DID, dans la collection app.bsky.feed.post et que son ID est 3le3esbhaek2l .

En plus de l'URI, le CID de la publication est également inclus, il s'agit d'un hachage unique généré à partir du contenu. Ces éléments forment ensemble le hachage de validation unique du référentiel.

Un autre aspect remarquable est la section thumb , qui fait référence à une image associée à la publication. Il s'agit d'un objet de type blob qui n'appartient à aucune collection. Le système stocke les fichiers volumineux (tels que les images, les vidéos, etc.) sous forme de blobs, qui peuvent être référencés dans des enregistrements individuels (par exemple, des publications) à l'aide de leur hachage (CID).

Pour ceux qui souhaitent examiner en profondeur la structure du référentiel et des enregistrements, l'outil go-repo-export peut être très utile. Avec ce petit programme, vous pouvez télécharger l'intégralité du référentiel utilisateur et extraire les collections et leurs enregistrements dans un répertoire au format JSON. Cela vous permet de voir exactement comment BlueSky stocke les données.

Chrome DevTools est une autre bonne source d'informations. Sur le site Web https://bsky.app , vous pouvez clairement voir les appels d'API et la manière dont le côté client communique avec le PDS.

Et bien sûr, il y a la documentation officielle. Le protocole AT et BlueSky ont une excellente documentation, et sur GitHub , vous pouvez trouver des exemples ainsi que le code source pour les côtés client et serveur.

Lorsque j’ai entendu parler pour la première fois du protocole AT, ma première pensée a été de savoir pourquoi nous avions besoin d’un autre protocole fédéré aux côtés d’ActivityPub . Cependant, le protocole AT possède en effet certaines caractéristiques qui justifient pleinement son existence. Le protocole n’est bien sûr pas parfait et subira probablement un développement important. Par exemple, si nous voulons construire un réseau véritablement résistant à la censure, il ne peut pas s’appuyer sur un système de noms de domaine centralisé. Un système de dénomination basé sur la blockchain, qui soit véritablement résistant à la censure, serait précieux (je pourrais même rédiger une proposition à ce sujet).

BlueSky compte actuellement entre 20 et 30 millions d'utilisateurs, ce qui est peu par rapport à la base d'utilisateurs de X (Twitter), mais cela reste significatif. Quant à ce que l'avenir nous réserve, personne ne peut le dire avec certitude. Le réseau fédéré est un avantage majeur, et il y a un débat intense sur la question de savoir si la possession par une seule entité d'une plateforme de communication mondiale comme Twitter ou Facebook est trop puissante. Je n'exclurais pas complètement la possibilité que BlueSky puisse un jour surpasser ses concurrents. Avec de bons générateurs de flux et une création de communauté efficace, cela est réalisable. Dans tous les cas, il vaut la peine de prêter attention à ce projet et de comprendre son fonctionnement.