El Protocolo AT ( Authentication Transfer Protocol , comúnmente abreviado como ATproto o atproto ) [1] [2] es un protocolo y estándar abierto para servicios de redes sociales descentralizadas . [3] Actualmente está siendo desarrollado por Bluesky Social PBC , una corporación de beneficio público creada originalmente como un grupo de investigación independiente dentro de Twitter para investigar la posibilidad de descentralizar el servicio. [4]
El Protocolo AT tiene como objetivo abordar los problemas percibidos con otros protocolos descentralizados, como la interoperabilidad de la plataforma , la capacidad de descubrimiento , la escalabilidad de la red y la portabilidad de los datos del usuario y los gráficos sociales . [3] Emplea una arquitectura de microservicio modular y una identidad de usuario federada e independiente del servidor para permitir un movimiento sin problemas entre los servicios del protocolo, con el objetivo de proporcionar una experiencia en línea integrada . [5] Las plataformas pueden acceder y servir cualquier contenido de usuario dentro de la red al obtener contenido formateado como esquemas de datos predefinidos de flujos de datos federados de toda la red . [6] [7]
El Protocolo AT impulsa la red social Bluesky , que fue creada como una prueba de concepto para el protocolo, y es el servicio principal en un ecosistema de plataformas y servicios construido sobre el Protocolo AT conocido como Atmosphere . [8] [9] [10] Bluesky Social se ha comprometido a transferir el desarrollo del protocolo a un organismo de normalización, como el Internet Engineering Task Force (IETF) , en el futuro. [11]
El Protocolo AT tiene como objetivo 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 en varias plataformas y servicios en línea. Bluesky Social describe el protocolo como "modelado a partir de la propia web abierta ". [5]
En comparación con otros protocolos para redes sociales como ActivityPub , donde las implementaciones generalmente están diseñadas como un servidor monolítico que aloja tanto los datos del usuario como la aplicación, divide estos elementos en microservicios más pequeños , que pueden usarse según sea necesario.
Los clientes y servicios del protocolo AT interactúan a través de una API HTTP llamada XRPC que utiliza principalmente JSON para la serialización de datos. [12] Además, todos los datos dentro del protocolo que deben ser autenticados , referenciados o almacenados están codificados en CBOR . [13]
El protocolo AT utiliza un sistema de identificador dual: un identificador de nombre de dominio mutable y un identificador descentralizado (DID) inmutable . Los identificadores sirven como identificadores del usuario y se verifican consultando los registros de recursos de un dominio . Los DID se resuelven en documentos DID, que contienen referencias a metadatos clave del usuario , como el identificador del usuario, las claves públicas y el repositorio de datos. [14]
Los servicios pueden asignar identificadores a los nuevos usuarios al registrarse mediante subdominios (por ejemplo, @username.bsky.social). Como alternativa, los usuarios pueden configurar un dominio o subdominio personalizado como su identificador (por ejemplo, @username.como @username.wikipedia.org) agregando un registro TXT a los registros del dominio que asocien el dominio o subdominio al DID del usuario. [15]
El sistema de doble identificador del protocolo proporciona identificadores fáciles de usar en servicios de usuario final e identidades criptográficas consistentes dentro del protocolo, al tiempo que proporciona un sólido mecanismo de verificación de cuentas basado en TCP/IP a nivel de protocolo.
Los datos de usuario dentro del protocolo se almacenan en repositorios de datos dedicados , o "repositorios". Cada usuario está asociado a un único repositorio, sobre el cual tiene derechos de gestión exclusivos. Los repositorios contienen colecciones mutables de registros de usuarios , que registran acciones como publicaciones, me gusta, seguidores y bloqueos. Los registros son persistentes y solo se pueden agregar o eliminar a pedido explícito del usuario. [16]
A cada registro dentro de la colección de un repositorio se le asigna una clave de registro única , que es utilizada por los agentes de red para hacer referencia a los registros dentro del repositorio de un usuario. La implementación actual de las claves de registro es el identificador de marca de tiempo (TID), derivado del tiempo de creación del registro. [17] Los repositorios almacenan colecciones en un árbol de búsqueda Merkle , que ordena los registros cronológicamente en función de su TID. [18]
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 host del usuario. [19] Esto permite que los agentes de red accedan y procesen archivos multimedia arbitrarios independientemente de su esquema original o contexto de carga. [20]
Los servidores de datos personales (PD) alojan repositorios de usuarios y sus medios asociados. También sirven como punto de acceso a la red para los usuarios, facilitando las actualizaciones de repositorios, las copias de seguridad, las consultas de datos y las solicitudes de los usuarios. [5]
Los clientes de la plataforma 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 difiere de ActivityPub , donde las interacciones y los servicios del protocolo son manejados por servidores host monolíticos. Dado que los eventos de red se resuelven a través de la infraestructura de indexación de toda la red del protocolo, los PDS son, por diseño, en gran medida intrascendentes para la experiencia del usuario. [21]
El Protocolo AT prioriza la portabilidad de datos , lo que permite a los usuarios realizar copias de seguridad y migrar repositorios y medios asociados sin pérdida de datos, incluso en el caso de un PDS adversario . [22] El diseño de los PDS dentro del protocolo da como resultado bajos requisitos computacionales para la operación, lo que permite que las personas o grupos ejecuten sus propios PDS sin la necesidad de recursos computacionales significativos. [3]
Aunque la mayoría de los repositorios de usuarios residen en PDS administrados por Bluesky Social, existen muchos PDS independientes dentro de la red. [2]
Los relés son un componente clave de la infraestructura de indexación del protocolo y funcionan como indexadores centrales dentro de la red. [5] Los relés rastrean la red al obtener continuamente actualizaciones del repositorio de los PDS antes de agregar , indexar y reenviar estas actualizaciones a flujos de datos de toda la red , colectivamente llamados manguera de incendios . [7] La manguera de incendios está disponible para todos los agentes de red y puede ser consumida por cualquier servicio dentro de la red. [3] Los relés pueden elegir indexar toda o parte de la red. [5]
Al eliminar la necesidad de rastrear o almacenar datos de usuario y proporcionar un flujo de datos unificado, los relés simplifican el desarrollo de aplicaciones y servicios en el protocolo y reducen sus costos operativos. [23]
Se ha criticado a los relés por ser el componente más centralizado en el diseño del protocolo, dado su papel casi indispensable en la red y la falta de incentivos claros para ejecutar un relé. [24] [25]
Las vistas de aplicaciones , análogas a los servicios de redes sociales actuales , son plataformas y servicios para usuarios finales dentro del protocolo que consumen, procesan y entregan datos desde el relé a los clientes usuarios en respuesta a las consultas de los PDS de los usuarios. Utilizan información de toda la red desde el relé, como publicaciones, me gusta, seguidores y respuestas, para crear experiencias de usuario personalizadas dentro de sus clientes. [3]
El diseño de App Views dentro del protocolo permite una variación significativa en la implementación. App Views puede implementar sistemas de invitación , algoritmos personalizados , clientes alternativos , diferentes estrategias de monetización y moderación de contenido y servicios fuera del protocolo. [26] A pesar de estas diferencias, todas las App Views operan a partir de los mismos datos provenientes de la manguera contra incendios. Esta arquitectura reduce la carga computacional y los requisitos de almacenamiento de App Views, y evita el bloqueo del usuario al permitir que los usuarios cambien fácilmente entre App Views mientras conservan sus publicaciones, seguidores, me gusta, etc. [27]
La vista de aplicación más grande en el 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 al estilo de Hacker News ) y Smoke Signal (un servicio de gestión de RSVP ) también están disponibles dentro del protocolo. [28] [29] [30]
Todas las publicaciones dentro del Protocolo AT siguen un lenguaje de esquema global específico llamado léxico para soportar diferentes modalidades de servicio y plataforma . [31] Las vistas de aplicaciones dentro del protocolo tienen la flexibilidad de definir sus propios léxicos únicos o utilizar los existentes.
Este enfoque permite que las vistas de aplicaciones creen léxicos personalizados que se adapten a su caso de uso específico y, al mismo tiempo, mantengan la compatibilidad con la red más amplia. Por ejemplo, los registros que se muestran en una vista de aplicación enfocada en microblogging probablemente usarían un léxico diferente al de uno enfocado en compartir videos , ya que sus tipos de contenido requieren diferentes conjuntos de atributos .
Sin embargo, las App Views también pueden elegir servir contenido utilizando léxicos definidos por otras App Views, incluso si el contenido fue publicado originalmente en otra parte de la red. [6] Por ejemplo, una nueva App View de microblogging podría elegir servir contenido publicado previamente utilizando el léxico definido por un competidor establecido, lo que le permitiría proporcionar características y servicios novedosos manteniendo la compatibilidad con el contenido existente.
Este diseño de esquema tiene como objetivo eliminar el bloqueo del usuario y fomentar la innovación centrada en el usuario al obligar a App Views a diferenciarse a través de experiencias de usuario únicas y funcionalidad adicional, en lugar de depender del acceso exclusivo al contenido. [32]
Los léxicos se referencian dentro de los registros mediante identificadores de espacios de nombres (NSID), que consisten en una autoridad de dominio en orden inverso al nombre de dominio , seguida de un segmento de nombre arbitrario. [33] Por ejemplo, com.example.fooBares un NSID válido, donde com.examplees la autoridad de dominio y fooBares el segmento de nombre.
El léxico más popular del protocolo, app.bsky, define el esquema de microblogging de Bluesky. [6]
Los servicios basados en opiniones son servicios dentro del protocolo que procesan datos de la manguera contra incendios para proporcionar juicios subjetivos sobre los datos de la red con el fin de moderar y curar el contenido . Estos servicios contrastan con la naturaleza "sin opiniones" prevista de los relés y las vistas de aplicaciones. [3] Los servicios basados en opiniones permiten a los usuarios personalizar sus preferencias de consumo y moderación de contenido dentro del protocolo, manteniendo al mismo tiempo la neutralidad de los componentes centrales del protocolo.
Los usuarios tienen la posibilidad de suscribirse y cancelar la suscripción a estos servicios en cualquier momento a través de su aplicación cliente (a menos que estén codificados en la vista de aplicación actual del usuario). [26] La modularidad de estos servicios permite un enfoque personalizable, apilable y centrado en el usuario para la curación y moderación de contenido dentro del protocolo. [34]
Los etiquetadores generan juicios sobre el contenido generado por el usuario, como identificar spam o material inapropiado. Estas etiquetas se pueden aplicar a varios aspectos de la red, incluidas publicaciones, imágenes o cuentas. El resultado de los etiquetadores es consumido por App Views y PDSes, que luego pueden proporcionar varias estrategias a los usuarios para manejar el contenido etiquetado, como ocultarlo, etiquetarlo o difuminarlo. [35]
Bluesky Social ha abierto el código fuente de su servicio de moderación de etiquetado interno "Ozone", lo que permite a los usuarios crear servicios de moderación personalizados para la red. [36] [34]
Aunque los etiquetadores se pueden utilizar como un servicio de moderación, también pueden tener fines informativos o de entretenimiento, como etiquetar temas de publicaciones, pronombres de usuario o agregar etiquetas positivas o divertidas a los perfiles y publicaciones de los usuarios. [37]
Los generadores de feeds procesan las publicaciones dentro de Firehose para incluirlas en feeds personalizados. Después de una consulta PDS, devuelven una lista de identificadores de publicaciones a la vista de la aplicación del usuario, que luego se puede usar para crear feeds seleccionados. [38] [39]
La implementación de referencia del protocolo se publicó por primera vez en GitHub el 4 de mayo de 2022 con el nombre de Experimento de datos autenticados (ADX) y tiene licencia MIT y Apache . [40] En octubre de 2022, pasó a denominarse Protocolo AT. [41]
El Protocolo AT ha sido adoptado para su uso por la red social Bluesky (también desarrollada por Bluesky Social PBC), y es su implementación más popular. La propia red social abrió la federación con otros servidores de datos personales a finales de febrero de 2024, ya que se había lanzado sin la capacidad de federarse con otros servidores que no fueran gestionados por Bluesky Social. [42] Además, el agregador de noticias Flipboard permite a los usuarios iniciar sesión con su cuenta de Bluesky para ver e interactuar con las publicaciones del servicio. [43] Para facilitar la adopción, Bluesky Social financia varios proyectos que utilizan el Protocolo AT para federar y/o crear contenido a través de subvenciones. [44] Una aplicación notable financiada por las subvenciones es un servidor proxy conocido como SkyBridge, que puede convertir las llamadas API de las aplicaciones Mastodon a sus API equivalentes del Protocolo AT/Bluesky, lo que permite a los usuarios tener acceso a ambas redes incluso sin el apoyo oficial. [45]
Si bien el Protocolo AT es un protocolo independiente sin grandes similitudes técnicas con otros protocolos, se han desarrollado servicios que pueden conectar contenido entre protocolos. Un ejemplo es el software Bridgy Fed, que puede publicar contenido entre ActivityPub y el Protocolo AT. [46] [47] Las publicaciones de Nostr también pueden "conectarse por doble puente" al Protocolo AT a través de otro puente que puede enviar notas de Nostr a ActivityPub. [48]