Pourquoi l'AT Protocol DID est l'identité que Bluesky ne perd jamais

Qu'est-ce qu'une AT Protocol DID?

Chaque compte Bluesky porte une AT Protocol DID, un identifiant persistant qu'AT Protocol attribue une fois et ne réattribue jamais à un autre compte. La spécification du protocole elle-même appelle la DID le "primary account identifier in atproto" ("identifiant principal de compte dans atproto"), construit sur la norme W3C d'identifiant décentralisé, et une DID typique ressemble à ceci : did:plc:ewvi7nxzyoun6zhxrhs64oiz. Considérez la DID comme le vrai nom du compte et le handle comme un surnom qui peut changer autour d'elle.

Que sont did:plc et did:web, et en quoi diffèrent-ils?

AT Protocol prend en charge exactement deux méthodes DID, did:plc et did:web, et chacune résout un identifiant vers les données d'un compte d'une manière différente. did:plc est une méthode conçue spécifiquement pour AT Protocol et elle est auto-authentifiante, ce qui signifie que l'identifiant lui-même porte assez d'information cryptographique pour vérifier sa propre histoire sans faire confiance à une autorité centrale au-delà de l'annuaire qui l'héberge. did:web est une méthode de la communauté W3C qui lie l'identifiant directement à un nom d'hôte via HTTPS, ce qui signifie que l'identité du compte dépend désormais du fait que ce domaine reste sous le contrôle du même propriétaire.

Qu'est-ce que l'annuaire PLC et qui le gère?

L'annuaire PLC est un registre public et gratuit qui résout les identifiants did:plc vers leurs documents DID actuels, et Bluesky Social PBC l'a construit et l'exploite comme infrastructure pour l'ensemble du réseau AT Protocol, pas comme un service réservé à Bluesky. L'annuaire se décrit lui-même comme "strongly consistent, recoverable, and allows for key rotation" ("fortement cohérent, récupérable, et permettant la rotation des clés"), en utilisant des journaux d'opérations auto-certifiants que n'importe qui peut vérifier de façon cryptographique plutôt qu'une blockchain ou un système de jetons. En octobre 2024, l'annuaire hébergeait plus de douze millions d'identifiants enregistrés, selon sa propre documentation.

En quoi une DID diffère-t-elle d'un handle Bluesky?

Une DID est l'identifiant stable qui ne change jamais, tandis qu'un handle est un nom d'utilisateur lisible par un humain, basé sur le DNS, que le propre guide du protocole de Bluesky traite explicitement comme réattribuable. L'objectif de conception du protocole est que les identités restent "portable across services" ("portables entre services"), de sorte que changer de fournisseur ou de domaine "should not cause a user to lose their identity, social graph, or content" ("ne devrait pas faire perdre à un utilisateur son identité, son graphe social ou son contenu"). Le handle est ce que les gens voient et tapent, mais chaque abonnement, publication et interaction côté serveur pointe toujours vers la DID en dessous.

Pourquoi un handle peut-il changer alors que la DID reste la même?

Un handle peut changer parce qu'il fonctionne comme un pointeur vers le compte, et non comme l'adresse réelle du compte, donc mettre à jour un handle de nom de domaine ou changer de fournisseur d'hébergement ne fait que réécrire le pointeur, pas l'identité qu'il désigne. Un utilisateur qui vérifie un domaine personnalisé comme handle, puis abandonne ensuite ce domaine, peut changer son handle à nouveau sans perdre ses abonnés, ses publications ou son historique, parce que chacun de ces enregistrements a toujours été lié à la DID. Cette séparation est la même raison pour laquelle un mot de passe d'application Bluesky peut être révoqué et réémis sans toucher à l'identité sous-jacente du compte : la révocation change les identifiants d'accès, pas le compte lui-même.

Comment résout-on une AT Protocol DID en pratique?

Résoudre une DID signifie transformer un handle en DID, puis transformer cette DID en un document DID complet, et le propre guide d'AT Protocol détaille les deux étapes. La résolution de handle vers DID fonctionne via un enregistrement DNS TXT à _atproto.<handle> ou via un point de terminaison well-known HTTPS sur le domaine du handle. Une fois que vous avez la DID elle-même, une did:plc se résout via une simple requête HTTP GET vers l'annuaire PLC, comme https://plc.directory/did:plc:ewvi7nxzyoun6zhxrhs64oiz, tandis qu'une did:web se résout directement via le domaine d'hébergement. Les deux chemins renvoient un document DID listant le handle actuel du compte, la clé de signature et l'URL du serveur de données personnel hébergeant son contenu.

Pourquoi cela compte-t-il pour suivre des comptes Bluesky dans le temps?

Les DID comptent pour suivre des comptes Bluesky dans le temps parce qu'un enregistrement basé uniquement sur le handle se casse dès que quelqu'un renomme son compte, alors qu'un enregistrement basé sur la DID continue de pointer vers le même compte, peu importe combien de fois le handle change. Tout outil construit sur la collecte de données des réseaux sociaux à travers Bluesky devrait résoudre et stocker la DID en plus du handle, pas le handle seul, sinon les mentions historiques et les données d'abonnés se déconnecteront silencieusement des comptes qui changent leur handle plus tard. Le suivi Bluesky de RedReplier suit les mentions au niveau du compte exactement pour cette raison, afin qu'une conversation suivie reste attribuée au bon compte même après un changement de handle.

Questions fréquentes

Un compte Bluesky peut-il avoir plus d'une DID?

Non. Chaque compte Bluesky est créé avec exactement une DID qui reste fixe pour toute la vie de ce compte, et basculer entre did:plc et did:web n'est pas une opération prise en charge une fois qu'un compte existe sur une méthode.

Que devient une DID si quelqu'un supprime son compte Bluesky?

Le document DID peut être marqué comme tombstoned (avec une pierre tombale) ou désactivé selon la méthode DID, mais l'identifiant lui-même n'est pas réattribué à un nouveau compte par la suite. La DID d'un compte supprimé ne devient pas disponible pour que quelqu'un d'autre la revendique.

Un compte did:web est-il moins sûr qu'un compte did:plc?

Pas intrinsèquement moins sûr, mais did:web lie la continuité du compte au maintien du contrôle d'un domaine spécifique, sans voie de récupération intégrée si ce domaine est perdu, tandis que did:plc prend en charge la rotation des clés et la récupération via les propres mécanismes de l'annuaire PLC. Le compromis oppose l'indépendance du domaine à la récupérabilité intégrée.

Ai-je besoin de comprendre les DID pour utiliser Bluesky en tant qu'utilisateur normal?

Non. L'interface de Bluesky n'affiche que des handles pendant l'usage normal, et la résolution de la DID se produit automatiquement en coulisses. Comprendre les DID importe surtout pour les développeurs, les chercheurs et toute personne construisant des outils au-dessus d'AT Protocol.

Puis-je rechercher moi-même la DID de n'importe quel compte Bluesky?

Oui. Résoudre un handle vers sa DID utilise une recherche DNS TXT ou une requête well-known HTTPS, toutes deux publiques et ne nécessitant aucun accès particulier, et l'annuaire PLC lui-même est un service public et interrogeable pour les comptes did:plc.

Changer un handle Bluesky affecte-t-il les résultats de recherche de ce compte?

Le comportement de la recherche dépend de la façon dont un outil donné indexe les comptes, mais AT Protocol lui-même résout les mentions et les abonnements via la DID, pas le handle, donc une implémentation bien construite des opérateurs de recherche Bluesky devrait continuer à renvoyer des résultats pour un compte après qu'il ait changé de handle.

À quoi ressemble concrètement une AT Protocol DID?

Une AT Protocol DID suit le format did:plc:... ou did:web:..., construit sur la norme W3C des identifiants décentralisés. Un exemple tiré de la documentation même du protocole est did:plc:ewvi7nxzyoun6zhxrhs64oiz. Le préfixe indique la méthode qui l'a attribuée, plc ou web, et ce qui suit est soit une chaîne générée, soit un nom de domaine.

Quelles informations contient un document DID?

Un document DID indique le handle actuel du compte, sa clé de signature et l'URL du serveur de données personnel qui héberge son contenu. Résoudre une DID, via l'annuaire PLC pour did:plc ou via le domaine d'hébergement pour did:web, renvoie exactement ce document. L'adresse du PDS qu'il contient est ce qu'un client utilise pour récupérer les publications et les données réelles d'un compte.

Pourquoi AT Protocol prend-il en charge deux méthodes de DID plutôt qu'une seule?

AT Protocol prend en charge did:plc et did:web parce que chacun cède quelque chose de différent. did:plc est auto-authentifiant et permet de récupérer un compte par rotation de clés sur l'annuaire PLC, tandis que did:web confie la pleine propriété de l'identifiant à quiconque contrôle un domaine, sans aucun moyen intégré de récupération si ce domaine est perdu. Proposer les deux permet à chaque titulaire de choisir la portabilité et la récupérabilité, ou l'indépendance vis-à-vis de son propre domaine, selon ce qui compte le plus pour lui.

Combien de comptes l'annuaire PLC recense-t-il?

Selon sa propre documentation, l'annuaire PLC recensait plus de douze millions d'identifiants en octobre 2024. Bluesky Social PBC exploite l'annuaire comme une infrastructure pour l'ensemble du réseau AT Protocol, pas seulement comme un service réservé à sa propre application. L'annuaire s'appuie sur des journaux d'opérations autocertifiés que chacun peut vérifier de façon cryptographique, sans blockchain ni système de jetons.