# Protocolo AT

El Protocolo AT ( en inglés: Authenticated Transfer Protocol, lit. 'Protocolo de transferencia autenticado'. comúnmente abreviado como ATProto) es un protocolo y estándar abierto para servicios descentralizados de redes sociales. Está siendo desarrollado por Bluesky Social PBC, una corporación de beneficio público originalmente creada como un grupo de investigación independiente dentro de Twitter para investigar la posibilidad de descentralizar la plataforma.
El Protocolo AT busca resolver problemas detectados en otros protocolos descentralizados, como la experiencia del usuario, la interoperabilidad entre plataformas, la capacidad de descubrimiento, la escalabilidad de la red, la portabilidad de los datos de usuario y los gráficos sociales. Emplea una arquitectura modular de microservicios y una identidad de usuario federada e independiente del servidor (server-agnostic) para permitir una transición fluida entre los servicios del protocolo, con el objetivo de ofrecer una experiencia en línea integrada. Las plataformas pueden acceder y servir cualquier contenido de usuario dentro de la red recuperando datos formateados como esquemas predefinidos desde flujos de datos federados a nivel de red.
El protocolo AT es la base de Bluesky, una red social creada como una prueba de concepto del protocolo, y es el servicio principal dentro de un ecosistema de plataformas y servicios construidos sobre el Protocolo AT, conocido como ATmosphere. Bluesky Social se ha comprometido a transferir el desarrollo del protocolo a un organismo de estándares, como el Internet Engineering Task Force (IETF), en un futuro cercano.

## Diseño

El objetivo del Protocolo AT es crear un ecosistema en línea descentralizado, interoperable y escalable donde los usuarios puedan conservar, gestionar y personalizar una única identidad en línea federada a través de diversas plataformas y servicios en línea. Bluesky Social describe el protocolo como un sistema "inspirado en la web abierta".
En comparación con otros protocolos para redes sociales, como ActivityPub, donde las implementaciones suelen diseñarse como un servidor monolítico que aloja tanto los datos del usuario como la aplicación, el Protocolo AT divide estos elementos en microservicios más pequeños que pueden utilizarse según las necesidades específicas.
Los clientes y servicios del Protocolo AT interoperan mediante una API HTTP llamada XRPC, que utiliza principalmente JSON para la serialización de datos. Además, todos los datos dentro del protocolo que deben ser autenticados, referenciados o almacenados están codificados en CBOR, un formato binario eficiente diseñado para datos estructurados.

### Identidad del usuario

El protocolo AT utiliza un sistema de identificación doble: un identificador mutable basado en un nombre de dominio (handle) y un identificador descentralizado (DID) inmutable. Los nombres de dominio sirven como identificadores para los usuarios y se verifican mediante la consulta de los registros de recursos de un dominio. Los DIDs se resuelven en documentos DID, los cuales contienen referencias a metadatos clave del usuario, como el dominio, las claves públicas y el repositorio de datos.
Los servicios pueden asignar handles a nuevos usuarios al registrarse, utilizando subdominios (por ejemplo, @usuario.bsky.social). Alternativamente, los usuarios pueden configurar un dominio o subdominio personalizado como su handle (por ejemplo, @usuario.com o @usuario.wikipedia.org), añadiendo un registro TXT a los registros del dominio o respondiendo a solicitudes HTTP en una URL específica del tipo .well-known, asociando así el dominio o subdominio con el DID del usuario.
El sistema de doble identificador del protocolo proporciona tanto identificadores fáciles de usar para los servicios de cara al usuario como identidades criptográficas consistentes dentro del protocolo, al mismo tiempo que implementa un robusto mecanismo de verificación de cuentas basado en TCP/IP a nivel del protocolo.

### Repositorios de datos del usuario

Los datos de usuario dentro del protocolo se almacenan en repositorios de datos dedicados, o repos. Cada usuario está asociado a un único repositorio, sobre el cual tiene derechos exclusivos de gestión. Los repositorios contienen colecciones mutables de registros de usuario, que registran acciones como publicaciones, "me gusta", seguimientos y bloqueos. Los registros son persistentes y solo pueden añadirse o eliminarse bajo solicitud explícita del usuario.
Cada registro dentro de la colección de un repositorio recibe una clave de registro única, utilizada por los agentes de la red para referenciar registros dentro del repositorio de un usuario. La implementación actual de las claves de registro utiliza identificadores de marca temporal (timestamp identifiers, TID), que se derivan del momento de creación del registro.
Los repositorios almacenan las colecciones en un árbol de búsqueda Merkle, que organiza los registros de forma cronológica basándose en su TID.
Los archivos multimedia, junto con sus metadatos, tamaño y tipo de medio, se almacenan por separado de los repositorios como blobs, un tipo de datos binarios no estructurados, en el servidor anfitrión del usuario. Esto permite que los agentes de la red accedan y procesen archivos multimedia arbitrarios, independientemente de su esquema original o contexto de carga.

### Servidores de Datos Personales

Los Servidores de Datos Personales (en inglés: Personal Data Servers, PDSes) alojan los repositorios de los usuarios junto con sus archivos multimedia asociados. También actúan como puntos de acceso a la red para los usuarios, facilitando actualizaciones de repositorios, respaldos, consultas de datos y solicitudes de usuario.
Los clientes de las plataformas acceden al protocolo en nombre del usuario consultando su PDS, que a su vez obtiene los datos solicitados de otros servicios dentro de la red. Este diseño se diferencia de ActivityPub, donde las interacciones del protocolo y los servicios se gestionan mediante servidores anfitriones monolíticos. Dado que los eventos de la red se resuelven a través de la infraestructura de indexación a nivel de red del protocolo, los PDSes, por diseño, tienen un impacto limitado en la experiencia del usuario.
El protocolo AT prioriza la portabilidad de los datos, permitiendo a los usuarios realizar respaldos y migrar sus repositorios y medios asociados sin pérdida de información, incluso en caso de enfrentarse a un PDS adverso. El diseño de los PDSes dentro del protocolo implica requisitos computacionales mínimos para su operación, lo que permite a individuos o grupos ejecutar sus propios PDSes sin necesidad de recursos significativos.
Aunque la mayoría de los repositorios de los usuarios residen en PDSes administrados por Bluesky, existen numerosos PDSes independientes dentro de la red.

### Relays y el Firehose

Los relays (relés) son un componente clave de la infraestructura de indexación del protocolo, funcionando como los indexadores centrales dentro de la red. Los relays recorren la red al obtener continuamente actualizaciones de los repositorios desde los PDSes, para luego agregarlas, indexarlas y reenviarlas en flujos de datos a nivel de red, conocidos colectivamente como el firehose. Este firehose está disponible para todos los agentes de la red y puede ser consumido por cualquier servicio dentro de la misma.
Los relays pueden optar por indexar la totalidad o solo una parte de la red. Al eliminar la necesidad de rastrear o almacenar datos de usuario y proporcionar un flujo de datos unificado, los relays simplifican el desarrollo de aplicaciones y servicios en el protocolo, además de reducir sus costos operativos.
Sin embargo, los relays han sido criticados por ser el componente más centralizado en el diseño del protocolo, dado su papel prácticamente indispensable en la red y la falta de incentivos claros para operar un relay.

### Vistas de Aplicación

Las Vistas de Aplicación (App Views), análogas a los servicios actuales de redes sociales, son plataformas y servicios de usuario final dentro del protocolo que consumen, procesan y entregan datos desde los relays a los clientes de usuario en respuesta a consultas realizadas desde los PDSes de los usuarios. Utilizan información a nivel de red proveniente del firehose, como publicaciones, "me gusta", seguimientos y respuestas, para crear experiencias personalizadas dentro de sus clientes.
El diseño de las vistas de aplicación dentro del protocolo permite una amplia variedad de implementaciones. Estas pueden incluir sistemas de invitación, algoritmos personalizados, clientes alternativos, estrategias diversas de monetización y moderación de contenido, así como servicios fuera del protocolo. A pesar de estas diferencias, todas las vistas de aplicación operan a partir de los mismos datos proporcionados por el firehose. Esta arquitectura reduce la carga computacional y los requisitos de almacenamiento de las vistas de aplicación, además de evitar la dependencia de un único servicio, permitiendo a los usuarios cambiar fácilmente entre Apps Views mientras conservan sus publicaciones, seguimientos, "me gusta", entre otros.
La Vista de Aplicación más grande del protocolo actualmente es Bluesky, aunque otras Vistas de Aplicación, como WhiteWind (una plataforma de blogs de formato largo), Frontpage (un sitio web de noticias sociales similar a Hacker News) y Smoke Signal (un servicio de gestión de RSVP), también están disponibles dentro del protocolo.

### Lexicons

Todas las publicaciones dentro del Protocolo AT siguen un lenguaje global de esquemas específico llamado lexicon, diseñado para admitir diferentes modalidades de servicios y plataformas. Las vistas de aplicación dentro del protocolo tienen la flexibilidad de definir sus propios lexicons únicos o utilizar los ya existentes.
Este enfoque permite a las vistas de aplicación crear lexicons personalizados adaptados a sus casos de uso específicos, manteniendo al mismo tiempo la compatibilidad con la red en general. Por ejemplo, los registros mostrados en una vistas de aplicación enfocada en microblogging probablemente usarían un lexicon diferente al de una enfocada en compartir videos, ya que los tipos de contenido requieren diferentes conjuntos de atributos.
Sin embargo, las vistas de aplicación también pueden optar por servir contenido utilizando lexicons definidos por otras vistas de aplicación, incluso si el contenido se publicó originalmente en otro lugar de la red. Por ejemplo, una nueva vistas de aplicación de microblogging podría elegir servir contenido previamente publicado utilizando el lexicon definido por un competidor establecido, lo que les permite ofrecer características y servicios novedosos mientras mantienen la compatibilidad con el contenido existente.
Este diseño de esquemas está pensado para eliminar la dependencia de un único servicio (user lock-in) y fomentar la innovación centrada en el usuario, obligando a las vistas de aplicación a diferenciarse mediante experiencias únicas y funcionalidades adicionales, en lugar de basarse en el acceso exclusivo al contenido.
Los lexicons se referencian dentro de los registros utilizando Identificadores con Espacios de Nombres (Namespaced Identifiers, NSIDs), que consisten en una autoridad de dominio en orden inverso al del nombre de dominio, seguida de un segmento de nombre arbitrario. Por ejemplo, com.appview.foo es un NSID válido, donde com.appview es la autoridad de dominio y foo es el segmento de nombre.
El lexicon más popular dentro del protocolo, app.bsky, define el esquema de microblogging de Bluesky.

### Etiquetadores

Los etiquetadores (labelers) generan juicios sobre contenido generado por usuarios, como la identificación de spam o material inapropiado. Estas etiquetas pueden aplicarse a diversos aspectos de la red, incluyendo publicaciones, imágenes o cuentas. El resultado producido por las etiquetas es consumido por las vistas de aplicación y los PDSes, que a su vez pueden ofrecer a los usuarios diferentes estrategias para gestionar el contenido etiquetado, como ocultarlo, etiquetarlo visualmente o desenfocarlo.
Bluesky Social ha publicado como código abierto su servicio interno de moderación mediante etiquetadores, llamado "Ozone", lo que permite a los usuarios crear servicios de moderación personalizados para la red.
Aunque los etiquetadores pueden utilizarse como un servicio de moderación, también pueden tener fines informativos o de entretenimiento, como etiquetar temas de publicaciones, pronombres de los usuarios o agregar etiquetas positivas o lúdicas a perfiles y publicaciones.

### Generadores de Feeds

Los Generadores de Feeds (Feed Generators) procesan publicaciones dentro del firehose para incluirlas en feeds personalizados. Tras una consulta desde un PDS, devuelven una lista de identificadores de publicaciones (post IDs) a la vistas de aplicación del usuario, que luego puede utilizarlos para crear feeds curados.

## Adopción

La implementación de referencia del protocolo se lanzó por primera vez en GitHub el 4 de mayo de 2022 bajo el nombre Authenticated Data Experiment (ADX), y está licenciada bajo las licencias MIT y Apache. En octubre de 2022, pasó a llamarse Protocolo AT.
El Protocolo AT ha sido adoptado para su uso por la red social Bluesky, y es su implementación más popular. La propia red social abrió la federación con otros Servidores de Datos Personales (Personal Data Servers) a finales de febrero de 2024, ya que originalmente se lanzó sin la capacidad de federarse con otros servidores que no estuvieran gestionados por Bluesky Social. Además, el agregador de noticias Flipboard permite a los usuarios iniciar sesión con su cuenta de Bluesky para ver e interactuar con publicaciones del servicio.
Para fomentar su adopción, Bluesky Social financia diversos proyectos que utilizan el Protocolo AT para federarse y/o crear contenido a través de subvenciones. Una aplicación notable financiada por estas subvenciones es un servidor proxy conocido como SkyBridge, que puede convertir las llamadas API de las aplicaciones de Mastodon a sus equivalentes en las APIs del Protocolo AT/Bluesky, permitiendo a los usuarios acceder a ambas redes, incluso sin soporte oficial.
Aunque el Protocolo AT es un protocolo independiente sin grandes similitudes técnicas con otros protocolos, se han desarrollado servicios que permiten interconectar contenido entre protocolos. Un ejemplo es el software Bridgy Fed, que permite publicar contenido entre ActivityPub y el Protocolo AT. Las publicaciones de Nostr también pueden ser "doblemente puenteadas" al Protocolo AT mediante otro puente que permite publicar notas de Nostr a ActivityPub.

## Críticas

Según Christine Lemmer-Webber, coautora del protocolo ActivityPub y de una propuesta interna temprana de arquitectura que finalmente no fue adoptada por Bluesky Social, "Bluesky no es verdaderamente descentralizado y ciertamente no está federado según ninguna definición técnica de federación que hayamos tenido previamente en el contexto de una red social descentralizada. Sin embargo, 'salida creíble' es un término razonable para describir lo que Bluesky está buscando".