Por qué la AT Protocol DID es la identidad que Bluesky nunca pierde

¿Qué es una AT Protocol DID?

Cada cuenta de Bluesky lleva una AT Protocol DID, un identificador persistente que AT Protocol asigna una vez y nunca reasigna a otra cuenta. La propia especificación del protocolo llama a la DID el "primary account identifier in atproto" ("identificador principal de cuenta en atproto"), construido sobre el estándar W3C de identificador descentralizado, y una DID típica se ve así: did:plc:ewvi7nxzyoun6zhxrhs64oiz. Trata la DID como el nombre real de la cuenta y el handle como un apodo que puede cambiar a su alrededor.

¿Qué son did:plc y did:web, y en qué se diferencian?

AT Protocol admite exactamente dos métodos DID, did:plc y did:web, y cada uno resuelve un identificador a los datos de una cuenta de una manera distinta. did:plc es un método construido específicamente para AT Protocol y es autoautenticable, lo que significa que el propio identificador lleva suficiente información criptográfica para verificar su propia historia sin confiar en una autoridad central más allá del directorio que lo aloja. did:web es un método de la comunidad W3C que ata el identificador directamente a un nombre de host sobre HTTPS, lo que significa que la identidad de la cuenta ahora depende de que ese dominio permanezca bajo el control del mismo propietario.

¿Qué es el directorio PLC y quién lo gestiona?

El directorio PLC es un registro público y gratuito que resuelve identificadores did:plc a sus documentos DID actuales, y Bluesky Social PBC lo construyó y lo opera como infraestructura para la red AT Protocol en general, no como un servicio exclusivo de Bluesky. El directorio se describe a sí mismo como "strongly consistent, recoverable, and allows for key rotation" ("fuertemente consistente, recuperable, y permite la rotación de claves"), usando registros de operaciones autocertificados que cualquiera puede verificar criptográficamente en lugar de una blockchain o un sistema de tokens. En octubre de 2024, el directorio alojaba más de doce millones de identificadores registrados, según su propia documentación.

¿En qué se diferencia una DID de un handle de Bluesky?

Una DID es el identificador estable que nunca cambia, mientras que un handle es un nombre de usuario legible por humanos y basado en DNS que la propia guía del protocolo de Bluesky trata explícitamente como reasignable. El objetivo de diseño del protocolo es que las identidades sigan siendo "portable across services" ("portables entre servicios"), de modo que cambiar de proveedor o de dominio "should not cause a user to lose their identity, social graph, or content" ("no debería hacer que un usuario pierda su identidad, su grafo social o su contenido"). El handle es lo que la gente ve y escribe, pero cada seguimiento, publicación e interacción en el backend sigue apuntando a la DID que hay debajo.

¿Por qué puede cambiar un handle mientras la DID permanece igual?

Un handle puede cambiar porque funciona como un puntero hacia la cuenta, no como la dirección real de la cuenta, así que actualizar un handle de nombre de dominio o cambiar de proveedor de alojamiento solo reescribe el puntero, no la identidad a la que apunta. Un usuario que verifica un dominio propio como su handle y luego abandona ese dominio puede actualizar su handle de nuevo sin perder seguidores, publicaciones o historial, porque cada uno de esos registros estuvo ligado a la DID desde el principio. Esta separación es la misma razón por la que una contraseña de aplicación de Bluesky puede revocarse y reemitirse sin tocar la identidad subyacente de la cuenta: la revocación cambia las credenciales de acceso, no la cuenta en sí.

¿Cómo se resuelve una AT Protocol DID en la práctica?

Resolver una DID significa convertir un handle en una DID y luego convertir esa DID en un documento DID completo, y la propia guía de AT Protocol expone ambos pasos. La resolución de handle a DID funciona mediante un registro DNS TXT en _atproto.<handle> o mediante un endpoint well-known de HTTPS en el dominio del handle. Una vez que tienes la DID en sí, una did:plc se resuelve mediante una simple petición HTTP GET al directorio PLC, como https://plc.directory/did:plc:ewvi7nxzyoun6zhxrhs64oiz, mientras que una did:web se resuelve directamente a través del dominio de alojamiento. Cualquiera de los dos caminos devuelve un documento DID que enumera el handle actual de la cuenta, la clave de firma y la URL del servidor de datos personal que aloja su contenido.

¿Por qué importa esto para hacer seguimiento de cuentas de Bluesky a lo largo del tiempo?

Las DID importan para hacer seguimiento de cuentas de Bluesky a lo largo del tiempo porque un registro basado solo en el handle se rompe en el momento en que alguien renombra su cuenta, mientras que un registro basado en DID sigue apuntando a la misma cuenta sin importar cuántas veces cambie el handle. Cualquier herramienta construida sobre la recopilación de datos de redes sociales en Bluesky debería resolver y guardar la DID junto con el handle, no solo el handle, o las menciones históricas y los datos de seguidores se desconectarán en silencio de las cuentas que renombren su handle más adelante. El monitoreo de Bluesky de RedReplier hace seguimiento de menciones a nivel de cuenta exactamente por esta razón, de modo que una conversación monitoreada siga atribuida a la cuenta correcta incluso después de un cambio de handle.

Preguntas frecuentes

¿Puede una cuenta de Bluesky tener más de una DID?

No. Cada cuenta de Bluesky se crea con exactamente una DID que permanece fija durante toda la vida de esa cuenta, y cambiar entre did:plc y did:web no es una operación admitida una vez que una cuenta existe en un método.

¿Qué pasa con una DID si alguien elimina su cuenta de Bluesky?

El documento DID puede marcarse como tombstoned (con lápida) o desactivado según el método DID, pero el identificador en sí no se reasigna a una nueva cuenta después. La DID de una cuenta eliminada no queda disponible para que otra persona la reclame.

¿Es una cuenta did:web menos segura que una cuenta did:plc?

No es inherentemente menos segura, pero did:web ata la continuidad de la cuenta a mantener el control de un dominio específico, sin una vía de recuperación integrada si ese dominio se pierde, mientras que did:plc admite rotación de claves y recuperación mediante los propios mecanismos del directorio PLC. El compromiso es independencia de dominio frente a recuperabilidad integrada.

¿Necesito entender las DID para usar Bluesky como usuario normal?

No. La interfaz de Bluesky solo muestra handles durante el uso normal, y la resolución de la DID ocurre automáticamente detrás de escena. Entender las DID importa sobre todo a desarrolladores, investigadores y a cualquiera que construya herramientas sobre AT Protocol.

¿Puedo buscar yo mismo la DID de cualquier cuenta de Bluesky?

Sí. Resolver un handle a su DID usa una consulta DNS TXT o una solicitud well-known de HTTPS, ambas públicas y sin necesidad de acceso especial, y el propio directorio PLC es un servicio público y consultable para cuentas did:plc.

¿Cambiar un handle de Bluesky afecta los resultados de búsqueda de esa cuenta?

El comportamiento de la búsqueda depende de cómo indexe las cuentas una herramienta determinada, pero AT Protocol en sí resuelve menciones y seguimientos a través de la DID, no del handle, así que una implementación bien construida de operadores de búsqueda de Bluesky debería seguir devolviendo resultados para una cuenta después de que cambie su handle.

¿Cómo es realmente una AT Protocol DID?

Una AT Protocol DID sigue el formato did:plc:... o did:web:..., construido sobre el estándar W3C de identificadores descentralizados. Un ejemplo real de la propia documentación del protocolo es did:plc:ewvi7nxzyoun6zhxrhs64oiz. El prefijo indica el método que la asignó, plc o web, y todo lo que sigue es una cadena generada o un nombre de dominio.

¿Qué información contiene un documento DID?

Un documento DID enumera el handle actual de la cuenta, su clave de firma y la URL del servidor de datos personal que aloja su contenido. Resolver una DID, a través del directorio PLC para did:plc o del dominio de alojamiento para did:web, devuelve exactamente ese documento. La dirección del PDS que contiene es la que un cliente usa para obtener los posts y los datos reales de una cuenta.

¿Por qué AT Protocol admite dos métodos de DID en lugar de uno?

AT Protocol admite did:plc y did:web porque cada uno cede algo distinto. did:plc es autoautenticable y permite recuperar la cuenta mediante rotación de claves en el directorio PLC, mientras que did:web entrega la propiedad completa del identificador a quien controle un dominio, sin ninguna forma integrada de recuperación si ese dominio se pierde. Ofrecer ambos deja que cada titular elija portabilidad y capacidad de recuperación, o independencia del propio dominio, según lo que más le importe.

¿Cuántas cuentas tiene registradas el directorio PLC?

Según su propia documentación, en octubre de 2024 el directorio PLC tenía registrados más de doce millones de identificadores. Bluesky Social PBC opera el directorio como infraestructura para toda la red de AT Protocol, no solo como un servicio de su propia aplicación. El directorio usa registros de operaciones autocertificados que cualquiera puede verificar de forma criptográfica, sin blockchain ni sistema de tokens.