Où se trouve `at://` ?

• Le protocole AT est le protocole qui sert de base aux réseaux sociaux décentralisés, et toutes les données y sont identifiées par des URI at://
• Un URI at:// désigne comme autorité le créateur des données (l’utilisateur), et il faut déterminer séparément l’emplacement où ces données sont effectivement hébergées
• La procédure de résolution d’un URI suit cet ordre : convertir le handle en identité (DID), identifier le serveur d’hébergement via la consultation du document DID, puis demander les données JSON à ce serveur
• Deux types de DID sont pris en charge (did:web, did:plc), avec des avantages, inconvénients et modes de conservation des données différents
• Cette approche met en avant le fait que la propriété des données appartient à l’utilisateur et garantit une persistance du lien même si le handle ou l’hébergement changent

---

Protocole AT, URI at:// et processus de résolution de l’identité des données sociales

# Structure de base du protocole AT et des URI at://

• Le protocole AT permet à plusieurs serveurs distribués de communiquer selon un standard donné, et l’ensemble est appelé l’« atmosphere »
• Chaque donnée dans l’atmosphere reçoit un URI unique commençant par at://, qui joue en quelque sorte le rôle d’un lien vers des données JSON
• Contrairement à la structure traditionnelle des URI, dans le protocole AT, c’est le créateur des données (l’utilisateur) qui est défini comme autorité de l’URI
  • Par exemple, dans la forme at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z, ruuuuu.de indique le propriétaire de ces données
• Le serveur physique où les données sont réellement hébergées n’est pas inclus directement dans l’URI, et il faut une procédure de résolution supplémentaire pour le trouver

# Les trois étapes de résolution d’un URI at://

• Pour faire correspondre un URI at:// à des données réelles (JSON), trois étapes sont nécessaires
  1. Convertir le handle (ruuuuu.de, etc.) en identité (DID: Decentralized Identifier)
     • Le handle est un alias servant à identifier l’utilisateur et peut changer
     • Il doit être converti en DID, un identifiant global immuable
     • Méthodes de conversion :
       • interroger l’enregistrement DNS TXT _atproto.<handle> → vérifier la valeur did=...
       • ou accéder à https://<handle>/.well-known/atproto-did
  2. Déterminer les informations d’hébergement des données via la consultation du document DID (DID Document)
     • Le document DID contient notamment la clé publique de cette identité et les service endpoints (serveurs)
     • Dans le cas de did:web:~, l’accès est basé sur le domaine (https://domaine/.well-known/did.json)
     • Dans le cas de did:plc:~, la consultation se fait via le répertoire PLC (https://plc.directory/DID)
     • Le service endpoint (serviceEndpoint) est le serveur réel d’hébergement des données
  3. Demander les données JSON via l’API du serveur d’hébergement
     • Transmettre les différentes parties de at:// comme paramètres à l’endpoint com.atproto.repo.getRecord pour demander les données
     • Le JSON renvoyé correspond aux données réelles associées à l’URI at://

# Explication du processus à travers un exemple

• Exemple : at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z
  • Étape 1 : ruuuuu.de → did:web:iam.ruuuuu.de (vérifié via un DNS TXT record ou .well-known)
  • Étape 2 : consultation du DID Document sur https://iam.ruuuuu.de/.well-known/did.json → serviceEndpoint vaut https://blacksky.app
  • Étape 3 : requête vers https://blacksky.app/xrpc/com.atproto.repo.getRecord?... → retour du JSON réel

    {
      "uri": "at://did:web:iam.ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z",
      "cid": "...",
      "value": {
        "text": "posting from did:web, like a boss",
        "$type": "app.bsky.feed.post",
        ...
      }
    }
    

• Même si le handle change, l’utilisation d’un URI at:// basé sur le DID (permalink) maintient le lien entre le compte et les données

# Différences entre did:web et did:plc

• did:web:
  • Permet de gérer et de vérifier son propre domaine
  • Si l’on perd le contrôle du domaine, on peut aussi perdre l’identifiant dans son ensemble
• did:plc:
  • C’est le PLC (Public Ledger of Credentials) qui opère l’identifiant
  • Il n’est pas rattaché à un domaine, mais un contrôle limité reste possible, par exemple si l’opérateur du PLC refuse des mises à jour
  • Tout l’historique des modifications peut être vérifié et tracé via des hashes

# Séparation entre identité, hébergement et données, et persistance

• at:// sépare l’identité et l’hébergement des données, ce qui permet la portabilité des données utilisateur et la création de liens permanents
• Le handle (surnom) peut être modifié à tout moment, et le serveur d’hébergement peut lui aussi être changé
• Le DID (identité) est immuable, et l’URI at:// fondé dessus peut servir de permalink persistant
• Le document DID contient à la fois la preuve de possession du handle, les clés de vérification de signature et les informations d’hébergement, garantissant fiabilité et flexibilité

# Applications concrètes et mention du développement

• En pratique, la majorité des applications basées sur AT reçoivent les données via WebSocket ou d’autres mécanismes push, puis les agrègent dans leur propre base de données interne
• Malgré cela, bien maîtriser la résolution des URI at:// reste indispensable pour comprendre les caractéristiques du réseau et assurer la portabilité des données
• Le système at:// fournit une abstraction de réseau social au-dessus de HTTP, DNS et JSON, et implémente techniquement le fait que la propriété des données appartient à l’utilisateur

# Conclusion

• Le protocole AT et les URI at:// font progresser techniquement l’identité, la connectivité et la persistance des données sociales
• Les développeurs doivent maîtriser le workflow central : résolution des handles, usage des DID, structure des documents DID et méthodes de requête des données réelles
• Grâce à cette architecture, il devient possible d’obtenir souplesse et propriété sur ses contenus, son identité et leur lieu d’hébergement

[GN⁺]

Avis Hacker News

• Inspiré par des articles récents sur ATProto, j’ai essayé de m’inscrire sur bsky, mais je n’y vois qu’un flot sans fin de politique américaine. Même en cliquant sans arrêt sur « voir moins de ce genre de posts », ça n’a presque aucun effet. Je me demande si c’est simplement la nature de cette plateforme. Devoir subir en permanence des avis prévisibles sur des polémiques étrangères un peu absurdes, ce n’est pas terrible mentalement.

  • Sur un nouveau compte, le flux « Discover » n’est vraiment pas fameux. Ça s’améliore un peu à mesure que les données de likes et de follows s’accumulent, mais on ne peut toujours pas dire qu’il soit excellent. Personnellement, je recommande plutôt le flux « For You » : il prend rapidement en compte les likes et pousse moins de contenu aléatoire. Le flux « Dev Trending » est aussi plutôt bon. For You Feed, Dev Trending
  • Ce que j’ai fait, c’est trouver quelques comptes corrects à suivre, puis masquer complètement l’onglet « Discovery ». Ensuite, j’ai agrandi naturellement ma liste d’abonnements en regardant les interactions des gens dans mes abonnés/abonnements. Sinon, je trouve aussi des comptes sur des blogs ou des sites web et je les suis. À mes yeux, c’est comme ça qu’un vrai réseau social devrait fonctionner ; recevoir de force du contenu recommandé automatiquement ne m’intéresse pas.
  • Heureusement, bsky propose un flux non algorithmique qui n’affiche que les posts des personnes que vous suivez. Je pense que c’est la seule façon de préserver sa santé mentale.
  • J’ai utilisé bsky pendant plus d’un an, et le contenu était majoritairement de la politique américaine. En tant qu’Européen, ça me paraît surtout être du bruit. Du coup, je suis retourné sur Mastodon. Pour suivre des gens du milieu tech, Mastodon était bien meilleur. Pour les actualités, je récupère tout en RSS via feedly. À ce stade, je ne vois même plus à quoi sert Bluesky ; j’ai juste l’impression que c’est une version de gauche de Twitter. La technologie était intéressante comme version plus avancée de Nostr, mais c’est tout.
  • Je recommande d’aller dans les réglages puis Contents and Media > Your Interests > News and Politics et de désactiver cette option. En revanche, si vous voulez voir des infos et contenus politiques d’un autre pays que les États-Unis, je ne connais pas vraiment de solution.

• Je ne sais toujours pas si ce projet résout réellement de manière significative les problèmes d’identité et de propriété des données. Côté identité, tout se résume à utiliser son propre domaine ou celui de quelqu’un d’autre (Bluesky, etc.). Comme la plupart des gens n’ont pas de domaine, leur identité finit de fait chez un tiers. Pour les données, c’est pareil : si votre compte est bloqué sur Bluesky ou sur un autre serveur, le stockage est fermé et vous perdez même l’occasion de déplacer vos données ailleurs. C’est exactement comme l’e-mail : sans votre propre domaine et votre propre serveur, vous ne contrôlez concrètement rien.

  • Dans AT, les données sont rattachées au DID (Decentralized Identifier) et non au handle ou à l’hébergement. C’est ce que j’explique en détail dans mon billet. Même si vous perdez le domaine de votre « handle », seul le handle devient invalide et l’application affiche quelque chose comme « invalid handle » à la place du nom d’utilisateur. Les données — posts, abonnés, etc. — restent accessibles via le DID. Le handle n’est qu’un pseudonyme. On peut d’ailleurs le changer via la fonction « changer de handle » de l’application. Pour l’hébergement, c’est similaire : même s’il existe des obstacles, tant que vous avez une sauvegarde du dépôt, vous pouvez migrer ailleurs. On peut automatiser ces sauvegardes, et il existe déjà des apps tierces qui le font. L’application officielle Bluesky permet aussi d’exporter le dépôt. Quand l’hébergeur coopère, on a des cas comme PDSMover. Et même s’il ne coopère pas, c’est possible, comme le montre adversarial pds migration. Aujourd’hui, ça demande des compétences techniques, mais j’espère que ce sera plus simple à l’avenir. Une fois le dépôt importé chez un nouvel hébergeur, vous récupérez la même identité, tous vos posts, vos abonnés, etc., sans différence apparente. C’est très différent de l’e-mail. C’est encore un peu difficile aujourd’hui, mais j’attends de l’écosystème AT qu’il rende tout cela bien plus simple.
  • Même quand on possède un domaine, on peut un jour le perdre. Contrairement à un serveur, un domaine dépend d’un bureau d’enregistrement, donc je trouve ça plus fragile. C’est pour cette raison que j’ai choisi un registrar soumis au droit de mon pays : en cas de problème, j’espère avoir un peu plus de chances de récupérer la situation.
  • La majorité des utilisateurs n’ayant pas de domaine restent toujours exposés au risque qui survient dès que l’hébergeur devient « hostile » — par exemple un blocage brutal du compte. Une protection complète suppose au final de posséder directement le domaine lui-même sous un TLD neutre et de router le trafic via DNS. Malgré cela, dans la réalité où presque personne n’utilisera son propre domaine, ce projet apporte tout de même une souplesse et une protection partielles, ce qui reste un progrès par rapport aux Big Social (Facebook, X, Instagram, etc.), où les données restent enfermées pour toujours. Bluesky semble s’y intéresser justement parce que, dans ce cadre, on peut garder le même handle tout en déplaçant seulement l’hébergement des données. À mon sens, l’industrie n’avance pas en atteignant la perfection d’un coup, mais en améliorant peu à peu des problèmes concrets.
  • À mon avis, la meilleure preuve d’identité reste la possession d’une clé privée. Pour l’hébergement, BitTorrent serait peut-être ce qu’il y a de plus robuste. On pourrait aussi imaginer stocker le contenu dans un dépôt git, signer les commits et les distribuer par torrent. Pour les notifications de mise à jour, j’avais pensé à NNTP ou RSS. Le problème, c’est surtout la découvrabilité et l’absence d’interactions, notamment de commentaires.
  • Au moins, avec l’e-mail, on peut emporter ses clés PGP/SMIME ailleurs. Je me demande si ATproto n’est pas fondé sur une idée comparable.

• Les explications de Dan sont toujours excellentes, et elles tombent à pic avec les récentes nouvelles sur le transfert du contrôle du PLC par Bluesky. Notre équipe a choisi le même système DID chez fair.pm pour distribuer de manière décentralisée des plugins WordPress — en gros, une gestion de paquets façon App Store. L’équipe de Bluesky, surtout Bryan, nous a beaucoup aidés, et nous avons même obtenu la prise en charge des clés Ed25519 pour pouvoir utiliser libsodium. Notre protocole est en cours de conception sur la base des DID et de la modération empilable de Bluesky, mais nous n’utilisons pas directement atproto. Le point important, c’est que les DID sont un standard du W3C, donc le PLC n’est pas lié à atproto.

  • Qui désigne ce « nous » ? Et si c’est une tentative de résoudre techniquement le drame WordPress, j’aimerais bien en savoir plus.
  • Tu dis que le PLC n’est pas dépendant d’atproto, mais le PLC (la méthode did) n’est-il pas au final lié à Bluesky ou à une autre autorité centrale ? Si c’est aussi centralisé, pourquoi appeler ça un DID ? did:plc n’est pas portable ; pourquoi ne pas avoir utilisé quelque chose comme did:web avec un fonctionnement équivalent au PLC ? Pourquoi ne pas avoir fait du method-specific-id un identifiant portable, par exemple basé sur le hash de la clé publique ? Et pourquoi ne pas être parti sur quelque chose de distribué comme un DHT, par exemple did:pkarr ? Le PLC ressemble au final à un autre système centralisé.

• Pour résoudre un at://, il faut envoyer une requête GET à plc.directory, et c’est à ce moment-là que le système semble redevenir un modèle 100 % centralisé. J’aurais au moins aimé qu’on puisse séparer du protocole plusieurs répertoires de confiance, un peu comme les racines DNS ou les autorités de certification.

  • Si vous voulez le faire individuellement, vous pouvez aussi utiliser did:web:fqdn. C’est également expliqué dans l’article.

• Tous les serveurs qui stockent des liens at:// devront finalement passer par DNS/HTTPS pour trouver la représentation canonique (permalink). Si DNSSEC n’est pas correctement mis en place, toute cette architecture me semble un peu fragile. Je n’y ai pas encore réfléchi en profondeur, mais ma crainte immédiate serait qu’avec un problème de type empoisonnement DNS, un attaquant puisse publier des messages en mon nom, puisque la clé publique figure dans le DID récupéré depuis le DNS.

  • L’empoisonnement DNS peut sembler inquiétant, mais dans la pratique ce n’est pas toujours le cas. Dans at://, il est courant de mettre un DID dans la partie autorité ; si l’on effectue les requêtes avec le DID plutôt qu’avec le handle, on dépend alors de HTTPS et du Web PKI. Même en partant d’un handle, on passe par le Web PKI et par des enregistrements TXT. L’approche recommandée, c’est de résoudre les handles côté serveur ; et si vous devez le faire directement, d’interroger un fournisseur DoH (DNS over HTTPS) de confiance. Ce n’est pas parfait, mais cela réduit fortement la surface d’attaque. DNSSEC est bien sûr une solution à ce problème, mais j’ai eu à plusieurs reprises de sérieux ennuis avec DNSSEC sur des réseaux en production. Par exemple, des sénateurs américains utilisent le domaine senate.gov pour vérifier leur identité, et récemment une mauvaise configuration DNSSEC a fait apparaître des dizaines de sénateurs avec « invalid handle » sur Bluesky. À cause de ce genre d’expérience décevante, je ne pousse pas actuellement à rendre DNSSEC obligatoire. Si un autre grand protocole réussissait à l’imposer avec succès, cela vaudrait le coup de reconsidérer la question.
  • Pour qu’un attaquant puisse publier en se faisant passer pour vous, il lui faut absolument la clé privée. L’enregistrement DNS indique seulement où récupérer le document DID, et ce document DID doit ensuite être vérifié de nouveau par DNS. Il existe une logique de validation dans ce processus. DNSSEC réduit bien le risque de falsification des enregistrements DNS, mais son absence ne permet pas à n’importe qui d’usurper votre identité et de publier en votre nom. Les serveurs rejetteront cela également.
  • Cette partie est un peu complexe, mais la méthode DNS TXT précise explicitement que « DNSSEC n’est pas requis ». Quoi qu’il en soit, DNS ne sert qu’à convertir Handle -> DID, et la validation est un processus bidirectionnel DID -> Handle.

• L’article ne donne pas assez d’informations sur les clés utilisées dans l’historique de modifications du DID. Par exemple, si je suis foobar.bsky.social, je ne me souviens pas avoir moi-même téléversé une clé, ni avoir reçu une consigne pour en télécharger une. Je me demande où se trouve exactement cette clé, qui la possède, et comment et quand elle est utilisée. Et si le DID se trouve sur plc.directory, quel mécanisme empêche l’exploitant du site d’écraser arbitrairement mon DID pour voler mon identité ?

• Le concept de at:// est intéressant. Mais je m’inquiète aussi des problèmes que peut poser dans la pratique un système fondé sur la propriété des données. Par exemple, si les utilisateurs possèdent leurs données, ils peuvent modifier ou supprimer le contenu à volonté. On peut publier un bon texte au départ, puis le réécrire de façon malveillante plus tard. Même si l’on conserve le hash des anciens messages pour empêcher ce genre d’altération, un nouveau service n’aura aucun moyen de connaître cet historique. Le suivi des likes ou des upvotes semble aussi difficile : si tout le monde stocke les objets chacun de son côté, retrouver qui a voté pour quoi n’a pas l’air simple. Et si quelqu’un crée de faux comptes pour ne pousser que ses propres contenus, il ne semble pas y avoir de vraie limite. Enfin, si un très grand nombre de comptes affluent depuis diverses plateformes, est-ce qu’il ne devient pas impossible de modérer le spam ou les activités malveillantes ? J’ai du mal à voir si, dans un modèle où chaque compte gère lui-même ses données, l’architecture du système tient vraiment pour la transparence, la responsabilité, la modération, l’anti-spam, etc.

  • Il suffit de publier aussi la gestion des versions (history). On peut inclure dans les données (json) toutes les informations souhaitées, donc on peut tout à fait décrire les anciennes adresses de posts en at:// sous forme de chaîne, comme une liste chaînée. Le DID répond aussi très bien à la question de la modération d’identité, c’est-à-dire qu’il fournit suffisamment d’éléments pour savoir qui est qui, bloquer ou juger en conséquence. L’idée essentielle, c’est que ce n’est pas une blockchain, mais un modèle centré sur le propriétaire des données, qui peut les partager à tout moment. C’est une structure plutôt séduisante tant que personne n’essaie activement de la saboter. Comme on sait clairement « quelles données de cette personne se trouvent où », cela apporte une certaine transparence. Si cet aspect ne vous intéresse pas, rien ne vous oblige à utiliser ce système.
  • Pour éviter les modifications malveillantes du contenu d’origine, il existe strongRef, un vrai permalink fondé sur un hash. Dan ne l’a pas détaillé dans l’article, mais si vous conservez le strongRef, vous pouvez immédiatement détecter qu’un ancien post a été modifié. C’est aussi pour cette raison que Bluesky n’a pas introduit de fonction d’édition : pour éviter les modifications malveillantes. (Références : résumé d’une expérimentation sur les permalinks, expérimentation sur l’historique d’édition des records). Pour le suivi des upvotes, on peut récupérer les données en crawlant le réseau et faire quelque chose d’approximatif avec des roaring bitmaps (exemple de roaring-bitmaps). Pour la modération, il y a la stackable moderation, qui est bien plus élégante que dans les systèmes existants. Il est aussi question de construire les labelers / feedgen comme un DAG, c’est-à-dire un système de composition de règles à base d’opérations ensemblistes. Quant à la falsification des données, les hash CID propres à chaque élément permettent de détecter les modifications. Le suivi de l’historique est également techniquement possible.

• Cela me donne un peu la même impression que de nombreux protocoles crypto qui parlent de décentralisation mais finissent malgré tout enfermés dans une seule plateforme.

  • C’est encore tôt, mais tangled.org (équivalent de GitHub) et leaflet.pub (équivalent de Medium) sont déjà activement utilisés. Avec des outils comme slices.network, qui automatisent l’indexation du réseau, la barrière à l’entrée pour développer de nouvelles apps baisse sans cesse, donc il y en aura probablement davantage. L’article explique comment cela fonctionne. Le point important, c’est que pour les utilisateurs « ordinaires », cette technologie n’a pas tant d’importance. La majorité des utilisateurs de Bluesky se moquent en réalité de la « décentralisation », voire y sont hostiles. Mais comme l’architecture décentralisée n’est pas directement visible dans le produit — un peu comme pour le Web — ce type d’adoption reste possible. Les gens veulent simplement que « ça marche ».
  • Ça fait aussi penser au passé de Git et GitHub : plus de fonctions sont arrivées, avec un peu plus de distribution et de souplesse au fil du temps.

• Il y a une question structurelle : « comment trouve-t-on le JSON avec un URI at:// ? » Même en lisant la documentation, je n’arrive pas à voir pourquoi on a besoin de « ce JSON-là ». Personnellement, cette approche ne me parle pas.

  • Désolé si l’introduction était un peu abrupte. Le protocole at:// permet d’embarquer et d’exporter librement des données entre applications, de partager une identité utilisateur, et de rendre possible l’auto-hébergement ou la migration des contenus. Il fournit des URI pérennes qui ne dépendent ni d’un handle ni d’un serveur. Le fonctionnement technique est expliqué dans l’ensemble du billet. Concrètement, comme leaflet.pub et bsky.app agrègent toutes deux des données depuis le même réseau public, elles peuvent afficher et relier facilement les données l’une de l’autre sans API dédiée (post de démonstration).
  • Pour aider à comprendre, on peut comparer cela à la question : « comment trouve-t-on du HTML à partir d’un URI https:// ? » C’est évidemment une simplification excessive, mais c’est une façon utile de l’expliquer à quelqu’un qui découvre DNS, HTTP et TLS.

• Je me demande si le protocole joue un rôle comparable à un immense topic Kafka public. Par exemple, quand on crée une nouvelle web app, est-ce qu’on ne peut pas se passer de stocker soi-même les données, laisser chaque utilisateur les stocker dans son propre espace, puis placer un listener qui écoute le tout pendant que le protocole garantit la propagation des données, de sorte que l’app n’ait plus qu’à écouter et mettre en cache ? Conceptuellement, c’est fascinant, mais je me demande aussi si des concepts de Kafka comme les offsets pour ne pas rater les mises à jour, ou les partitions pour passer à l’échelle, s’appliquent ici.

  • Oui, le firehose remplit pratiquement ce rôle. N’importe qui peut s’y abonner ou exécuter son propre firehose. Voir ATProto pour les ingénieurs en systèmes distribués. Le firehose et jetstream disposent de curseurs, donc même si l’on se connecte en retard, on peut quand même recevoir les mises à jour jusqu’aux données les plus récentes. La fenêtre de couverture dépend de l’instance et va de 1 à 72 heures. Si vous avez besoin de l’historique complet, vous pouvez le traiter en backfill.