Dónde está `at://`

• El protocolo AT es la base de una red social descentralizada, y todos los datos se identifican con un URI at://
• Un URI at:// usa como authority al creador de los datos (usuario), y la ubicación donde esos datos están realmente alojados debe resolverse por separado
• El proceso de resolución del URI sigue este orden: convertir el handle en una identidad (DID), identificar el servidor de alojamiento consultando el documento DID, y luego solicitar los datos JSON a ese servidor
• Se admiten dos métodos de DID (did:web, did:plc), cada uno con distintas ventajas, desventajas y formas de preservar los datos
• Este enfoque enfatiza que la propiedad de los datos pertenece al usuario y garantiza una persistencia que mantiene el vínculo aunque cambien el handle o el alojamiento

---

Protocolo AT, URI at:// y el proceso de resolución de identidad de los datos sociales

# Estructura básica del protocolo AT y del URI at://

• El protocolo AT permite que múltiples servidores distribuidos se comuniquen siguiendo un estándar específico, y al conjunto completo se le llama atmosphere
• A cada dato dentro del atmosphere se le asigna un URI único que comienza con at://, y este URI funciona como una especie de enlace a datos JSON
• A diferencia de la estructura tradicional de un URI, en el protocolo AT el authority se establece como el creador de los datos (usuario)
  • Por ejemplo, en la forma at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z, ruuuuu.de indica que es el propietario de esos datos
• El servidor físico donde se alojan realmente los datos no está incluido directamente en el URI, por lo que se necesita un proceso adicional de resolución para encontrarlo

# Las tres etapas del proceso de resolución de un URI at://

• Para mapear un URI at:// a los datos reales (JSON) se necesitan tres etapas
  1. Convertir el handle (ruuuuu.de, etc.) en una identidad (DID: Decentralized Identifier)
     • El handle es un alias para identificar al usuario y puede cambiar
     • Por eso es necesario convertirlo a un DID, que es un ID global inmutable
     • Formas de conversión:
       • Consultar el registro DNS TXT de _atproto.<handle> → verificar el valor did=...
       • O acceder a https://<handle>/.well-known/atproto-did
  2. Confirmar la información de alojamiento de los datos mediante la consulta del documento DID (DID Document)
     • El documento DID incluye información como la clave pública de esa identidad y el endpoint del servicio (servidor)
     • En el caso de did:web:~, se accede con base en el dominio (https://dominio/.well-known/did.json)
     • En el caso de did:plc:~, se consulta en el directorio PLC (https://plc.directory/DID)
     • El endpoint de servicio (serviceEndpoint) es el servidor real donde se alojan los datos
  3. Solicitar los datos JSON a través de la API del servidor de alojamiento
     • Se solicitan los datos al endpoint com.atproto.repo.getRecord, pasando como parámetros las partes del at://
     • El JSON devuelto es el dato real mapeado al URI at://

# Explicación del proceso de resolución con un ejemplo

• Ejemplo: at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z
  • Paso 1: ruuuuu.de → did:web:iam.ruuuuu.de (se confirma mediante el registro DNS TXT o .well-known)
  • Paso 2: consultar el DID Document en https://iam.ruuuuu.de/.well-known/did.json → serviceEndpoint es https://blacksky.app
  • Paso 3: hacer una solicitud a https://blacksky.app/xrpc/com.atproto.repo.getRecord?... → se devuelve el JSON real

    {
      "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",
        ...
      }
    }
    

• Aunque cambie el handle, si se usa un URI at:// basado en DID (permalink), se mantiene el vínculo entre la cuenta y los datos

# Diferencias entre los métodos DID: did:web y did:plc

• did:web:
  • Permite administrar y verificar tu propio dominio
  • Si se pierde el control del dominio, existe la posibilidad de perder toda la identidad
• did:plc:
  • PLC (Public Ledger of Credentials) es la entidad que opera la identidad
  • No depende de un dominio, pero existe la posibilidad de un control limitado, por ejemplo si el operador de PLC rechaza actualizaciones
  • Todo el historial de cambios puede verificarse y rastrearse mediante hashes

# Separación entre identidad, alojamiento y datos, y su persistencia

• at:// separa la identidad del alojamiento de los datos, lo que hace posible portar los datos del usuario y crear enlaces permanentes
• El handle (apodo) puede cambiar en cualquier momento, y el servidor de alojamiento también puede migrarse del mismo modo
• El DID (identidad) es inmutable, y un URI at:// basado en él puede usarse como permalink persistente
• El DID Document contiene la prueba de propiedad del handle, las claves para verificar firmas y la información de alojamiento, lo que garantiza confiabilidad y flexibilidad

# Aplicación real y notas para desarrollo

• En la práctica, la mayoría de las apps basadas en AT reciben datos por push mediante WebSocket, entre otros métodos, y los agregan a su base de datos interna
• Aun así, entender cómo resolver un URI at:// es esencial para comprender las características de la red y asegurar la portabilidad de los datos
• El esquema at:// ofrece una abstracción de red social sobre HTTP, DNS y JSON, e implementa técnicamente la idea de que la propiedad de los datos pertenece al usuario

# Conclusión

• El protocolo AT y el URI at:// llevan la identidad, la conectividad y la persistencia de los datos sociales a un nivel técnicamente más avanzado
• Los desarrolladores necesitan dominar el flujo de trabajo clave, como la resolución de handles, el uso de DID, la estructura del DID Document y la forma de solicitar los datos reales
• Gracias a esta estructura, es posible obtener flexibilidad y propiedad sobre el contenido, la identidad y la ubicación de alojamiento

[GN⁺]

Comentarios de Hacker News

• Hace poco vi un artículo sobre ATProto y me animé a unirme a bsky, pero todo lo que veo es un flujo interminable de política estadounidense; aunque siga presionando “ver menos de esto”, casi no ayuda. Me pregunto si esa es la esencia de esta plataforma. Mentalmente me agota tener que seguir viendo opiniones obvias sobre discusiones raras de otros países.

  • En cuentas nuevas, el feed "Discover" no es muy bueno. Mejora conforme se acumulan datos de likes y follows, pero aun así no diría que sea excelente. Personalmente recomiendo el feed "For You"; refleja los likes rápido y empuja menos contenido aleatorio. El feed "Dev Trending" también está bastante bien. For You Feed, Dev Trending
  • Lo que hice fue encontrar algunas cuentas decentes para seguir y oculté por completo la pestaña "Discovery". Después de eso, fui ampliando de forma natural mi lista de seguidos viendo las interacciones de la gente en mis seguidores/seguidos. También busqué cuentas en blogs o sitios web y las seguí. Creo que así es como realmente debería funcionar una red social; no me gusta que me fuercen contenido recomendado automatizado.
  • Por suerte, bsky tiene un feed no algorítmico que muestra solo las publicaciones de la gente que sigues. Creo que esa es la única forma de proteger la salud mental.
  • Usé bsky por más de un año, pero la mayor parte del contenido era política de Estados Unidos. Como europeo, para mí solo era ruido, así que terminé regresando a Mastodon. Para seguir gente del mundo tech, Mastodon me funcionó mucho mejor. Todas las noticias las recibo por RSS en feedly. A estas alturas ya ni sé para qué necesito Bluesky; se siente como una versión de izquierda de Twitter. La tecnología me pareció interesante como una evolución de Nostr, pero hasta ahí.
  • Recomiendo ir a Settings > Contents and Media > Your Interests y desactivar News and Politics. Si lo que quieres es ver noticias y contenido político de otros países que no sean Estados Unidos, no conozco un buen método.

• Todavía no sé si este proyecto realmente resuelve de forma significativa los problemas de identidad y propiedad de datos. En el lado de la identidad, básicamente todo se reduce a usar tu propio dominio o el dominio de otra persona (como Bluesky). Como la mayoría no tiene dominio, al final su identidad queda en manos de un tercero. Con los datos pasa algo parecido: si tu cuenta es bloqueada en Bluesky u otro servidor, también se cierra tu almacenamiento y ni siquiera tienes oportunidad de mover tus datos a otro lugar. Esto es igual que con el correo electrónico: si no tienes tu propio dominio y tu propio servidor, en la práctica no controlas nada.

  • En AT, los datos no pertenecen al handle ni al hosting, sino al DID (Decentralized Identifier, identificador descentralizado). En mi artículo expliqué esto con más detalle. Si pierdes el dominio de tu "handle", lo único que pasa es que el handle queda invalidado y en la app aparece algo como "invalid handle" en lugar del nombre de usuario. Tus publicaciones, seguidores y demás datos siguen ahí porque pueden consultarse mediante el DID. El handle es solo una especie de apodo. También puedes cambiarlo desde la función "cambiar handle" de la app. Con el hosting pasa algo similar: aunque hay obstáculos, si tienes un respaldo del repositorio puedes moverlo a otro lugar. Incluso se puede automatizar el respaldo, y ya existen apps de terceros que hacen respaldos automáticos. La app oficial de Bluesky también permite exportar el repositorio. Cuando el proveedor de hosting coopera, existen casos como PDSMover; e incluso si no coopera, según adversarial pds migration también es posible. Hoy todavía se necesita conocimiento técnico, pero espero que con el tiempo este proceso se vuelva más fácil. Si subes tu repositorio a un nuevo host, recuperas sin diferencia tu misma identidad, todas tus publicaciones, seguidores, etc. Esto es muy distinto al correo electrónico. Ahora es algo difícil, pero espero que conforme madure el ecosistema AT se vuelva muchísimo más cómodo.
  • Incluso si tienes un dominio, puede llegar el día en que lo pierdas. A diferencia de un servidor, un dominio depende de un registrador, así que me parece algo más frágil. Por eso elegí un registrador que está bajo la legislación de mi país; así, si ocurre un problema, al menos siento que hay más posibilidades de recuperación.
  • La mayoría de usuarios que no tienen dominio siempre están expuestos al riesgo que aparece cuando el proveedor de hosting se vuelve el "enemigo" (por ejemplo, un bloqueo repentino de cuenta). La única defensa completa sería poseer directamente un dominio bajo un TLD neutral y enrutar el tráfico vía DNS. Aun así, bajo esta realidad —que casi nadie va a usar su propio dominio—, este proyecto sí agrega cierta flexibilidad y protección parcial, lo cual ya es un avance frente a las Big Social tradicionales (Facebook, X, Instagram, etc.), donde tus datos quedan atrapados para siempre. Parece que Bluesky apunta justo a ese entorno, porque permite incluso mover solo el hosting de los datos sin cambiar el handle. Creo que la industria no puede alcanzar la perfección de golpe; avanza mejorando poco a poco problemas reales.
  • Creo que la mejor prueba de identidad es la posesión de una clave privada. Para el hosting, me da la impresión de que BitTorrent sería de lo más robusto. También podría considerarse guardar el contenido en un repositorio git, firmar los commits y distribuirlo por torrent. Para avisos de actualizaciones, había pensado en NNTP o RSS. El problema sería la capacidad de descubrimiento y la falta de interacción (sin comentarios).
  • Al menos en el correo puedes llevarte tus claves PGP/SMIME a otro lado. Me pregunto si ATproto no apunta a un concepto parecido.

• Las explicaciones de Dan siempre son excelentes, y llegan justo a tiempo con la noticia reciente de que Bluesky transferirá el control operativo de PLC. Nuestro equipo también eligió este mismo sistema DID en fair.pm para la distribución descentralizada de plugins de WordPress (digamos, algo así como gestión de paquetes al estilo App Store). La gente de Bluesky —especialmente Bryan— nos ayudó bastante, y hasta conseguimos soporte para claves Ed25519 para poder usar libsodium. Nuestro protocolo está siendo diseñado sobre DID y la moderación apilable de Bluesky, aunque no usa atproto directamente. Lo importante es que DID es un estándar del W3C, así que PLC no está atado a atproto.

  • Me gustaría saber quiénes son "nosotros" y, si esto es un intento de resolver técnicamente el drama de WordPress, me interesaría una explicación un poco más detallada.
  • Dices que PLC no depende de atproto, pero ¿no queda PLC (el método did) finalmente atado a Bluesky o a alguna autoridad central? Si es tan centralizado, me pregunto por qué llamarlo DID. did:plc tampoco es portable. También me pregunto por qué no se escribió como did:web con un comportamiento tipo PLC, por qué el method-specific-id no se hizo portable usando algo como un hash de clave pública, o por qué no se fue por algo descentralizado como un DHT (por ejemplo, did:pkarr). PLC al final me parece otro sistema centralizado más.

• Para resolver at://, al final hay que hacer un GET a plc.directory, y en ese punto parece que el sistema se vuelve 100% centralizado. Como mínimo, me habría gustado que existieran varios directorios de confianza separados del protocolo, algo como las raíces DNS o las CA.

  • Si quieres hacerlo por tu cuenta, también puedes usar did:web:fqdn. Eso también lo explico en el artículo.

• Todos los servidores que guarden enlaces at:// probablemente tengan que pasar por DNS/HTTPS para encontrar la representación canónica (permalink). Si DNSSEC no está bien implementado, esta estructura se ve algo frágil. No lo he pensado a fondo, pero una preocupación inmediata es que, con algo como envenenamiento de DNS, un atacante podría publicar entradas a mi nombre (ya que la clave pública está en el DID obtenido por DNS).

  • Es razonable preocuparse por el envenenamiento de DNS, pero en la práctica no siempre aplica así. En at://, lo común es poner un DID en la parte de autoridad, así que si haces la solicitud por DID en vez de por handle, al final dependes de HTTPS y del web PKI. Incluso si empiezas desde el handle, terminas pasando por web PKI y por un registro TXT. La forma recomendada es resolver los handles del lado del servidor y, si necesitas hacerlo directamente, consultar a un proveedor de DoH (DNS sobre HTTPS) de confianza. No es perfecto, pero reduce bastante la superficie de ataque. DNSSEC sí sería una solución para ese problema, por supuesto, pero en redes de producción me ha tocado pasar por varios problemas con DNSSEC. Por ejemplo, senadores de Estados Unidos usan el dominio senate.gov para verificar identidad, y hace poco una mala configuración de DNSSEC provocó que decenas de senadores aparecieran con "invalid handle" en Bluesky. Por experiencias frustrantes como esa, por ahora no estamos impulsando con fuerza hacer obligatorio DNSSEC. Si otro protocolo grande lograra imponer DNSSEC con éxito, valdría la pena reconsiderarlo.
  • Para que un atacante publique haciéndose pasar por ti, necesariamente necesita tu clave privada. El registro DNS solo indica dónde obtener el documento DID, y ese documento DID debe volver a validarse contra DNS. Hay una lógica de verificación en este proceso. DNSSEC reduce el riesgo de manipulación de registros DNS, pero aunque no haya DNSSEC, no es posible que un tercero cualquiera publique haciéndose pasar por ti; el servidor también lo rechazaría.
  • Esa parte es un poco compleja, pero el método DNS TXT dice explícitamente "DNSSEC no requerido". En cualquier caso, DNS solo se encarga de la conversión Handle->DID, mientras que la validación es un proceso bidireccional que también pasa por DID->Handle.

• En el artículo faltó información sobre las claves usadas para el historial de cambios del DID. Por ejemplo, si yo fuera foobar.bsky.social, no recuerdo haber subido yo mismo una clave ni haber recibido instrucciones para descargarla. Me pregunto exactamente dónde está esa clave, quién la posee y cómo y cuándo se usa. También quisiera saber qué mecanismo impide que el operador de plc.directory sobrescriba arbitrariamente mi DID y robe mi identidad.

• El concepto de at:// me parece interesante, pero me preocupan algunos problemas que pueden surgir en un sistema basado en propiedad real de los datos. Por ejemplo, si el usuario controla sus datos, entonces puede cambiar o borrar el contenido cuando quiera. Puede escribir algo razonable al principio y luego modificarlo maliciosamente después. Aunque uno guarde hashes de entradas viejas para evitar cambios, los servicios nuevos no tendrían forma de conocer ese historial. También parece difícil rastrear cosas como los upvotes. Si cada quien guarda todo como objetos propios, ni siquiera queda claro cómo saber quién dio upvote. Y si alguien crea cuentas falsas para seguir promocionando sus propios posts, tampoco parece haber demasiadas limitaciones. Por último, si hay un número enorme de cuentas provenientes de distintas plataformas, ¿no sería imposible moderar el spam o la actividad maliciosa? Si partimos de que cada cuenta administra por sí misma sus datos, no termino de ver cómo encaja el diseño completo del sistema en términos de transparencia, responsabilidad, moderación y bloqueo de spam.

  • La gestión del cambio (history) puede publicarse junto con los datos. Como puedes incluir en el JSON toda la información que quieras, es posible describir una publicación anterior mediante at:// como una lista enlazada continua. DID también explica bastante bien la moderación de identidad; es decir, ofrece base suficiente para saber quién es alguien, bloquearlo o juzgarlo. El punto es que esto no es blockchain, sino una forma centrada en el propietario de los datos y compartible en cualquier momento. A menos que alguien tenga intenciones maliciosas de arruinarlo todo, me parece una estructura bastante atractiva. Como deja claro "qué datos de esta persona están dónde", si todo eso de la transparencia no te interesa, tampoco tienes por qué usarlo.
  • Para evitar modificaciones maliciosas del contenido original existe strongRef, que es un permalink real basado en hash. Dan no entra en detalle sobre eso en el artículo, pero si guardas el strongRef, podrás detectar rápido cualquier cambio en una publicación previa. Bluesky tampoco ha introducido edición precisamente por el riesgo de modificaciones maliciosas. (Referencia: resumen de experimento sobre permalinks, experimento de historial de edición de registros). El seguimiento de upvotes se puede hacer más o menos recolectando datos de la red y usando cosas como roaring bitmap (ejemplo de roaring-bitmaps). Para el problema de moderación existe stackable moderation, que es muchísimo más interesante que los sistemas tradicionales. También hay discusiones sobre construir labeler/feedgen como un DAG (un sistema de composición de reglas basado en operaciones de conjuntos). Los problemas de falsificación de datos se detectan por medio del hash CID de cada objeto, y el seguimiento del historial de cambios también es técnicamente posible.

• Me da una sensación parecida a la de muchos protocolos cripto que hablan de descentralización, pero que al final igual terminan amarrados a una sola plataforma.

  • Todavía está en etapa temprana, pero ya se usan bastante tangled.org (parecido a GitHub) y leaflet.pub (parecido a Medium). Además, siguen bajando las barreras para crear nuevas apps gracias a herramientas que indexan automáticamente la red, como slices.network. En el artículo explico cómo funciona. Lo importante es que a los usuarios "normales" este tipo de tecnología en realidad no les importa mucho. La mayoría de usuarios de Bluesky, de hecho, son indiferentes o incluso hostiles a la idea de la "descentralización". Pero como esa estructura descentralizada no se muestra directamente en el producto —igual que pasa con la navegación web—, creo que este tipo de adopción sí puede ocurrir. La gente solo quiere que "funcione bien".
  • También se siente un poco parecido a la historia de Git y GitHub (con más funciones, se fue volviendo un poco más distribuido y flexible).

• Tengo una duda estructural: "¿cómo se obtiene JSON a partir de un URI at://?". Aunque leo la documentación, no termino de entender por qué hace falta "ese JSON". Personalmente, este enfoque no me convence.

  • Perdón si la introducción fue muy abrupta. El protocolo at:// permite incrustar y exportar datos libremente entre apps, compartir identidad de usuario y habilitar autoalojamiento o migración de contenido. También ofrece URIs permanentes que no dependen del handle ni del servidor. El funcionamiento técnico se explica a lo largo del artículo. Como ejemplo práctico, leaflet.pub y bsky.app son dos apps que agregan datos de la misma red pública, así que pueden mostrar e interoperar fácilmente con los datos de la otra sin necesidad de una API separada (post de demostración).
  • Para ayudar a entenderlo, se puede comparar con la pregunta: "¿cómo se obtiene HTML a partir de un URI https://?". Es una simplificación excesiva, pero sirve para explicárselo a alguien que está aprendiendo DNS, HTTP y TLS por primera vez.

• Me pregunto si el protocolo funciona como una especie de gran tópico público de Kafka. Por ejemplo, al crear una nueva app web, en vez de guardar datos directamente, cada usuario guardaría sus datos en su propio espacio, habría listeners que los escuchan, y el protocolo garantizaría la propagación para que la app solo escuche y haga caché. Conceptualmente suena interesante, pero también me pregunto si aplican ideas de Kafka como offsets para no perder actualizaciones o particiones para escalar.

  • Sí, el firehose cumple casi exactamente ese papel. Cualquiera puede suscribirse o incluso correr su propio firehose. Mira ATProto para ingenieros de sistemas distribuidos. firehose y jetstream tienen cursores, así que aunque te conectes tarde puedes seguir recibiendo actualizaciones hasta alcanzar los datos más recientes. El período de cobertura depende de la instancia y suele estar entre 1 y 72 horas. Si necesitas el historial completo, puedes manejarlo con un proceso de backfill.