Protocol AT

El Protocol AT ( en inglés: Authenticated Transfer Protocol, lit. 'Protocol de transferència autenticado'. comunament abreviat com ATProto) és un protocol i estàndart obert per a servicis descentralisats de rets socials. Està sent desenrollat per Bluesky Social PBC, una corporació de benefici públic originalment creada com un grup d'investigació independent dins de Twitter per a investigar la possibilitat de descentralisar la plataforma.

El Protocol AT busca resoldre problemes detectats en atres protocols descentralisats, com l'experiència de l'usuari, l'interoperabilidad entre plataformes, la capacitat de descobriment, l'escalabilidad de la ret, la portabilitat de les senyes d'usuari i els gràfics socials. Ampra una arquitectura modular de microservicios i una identitat d'usuari federada i independent del servidor (server-agnostic) per a permetre una transició decorreguda entre els servicis del protocol, en l'objectiu d'oferir una experiència en llínea integrada. Les plataformes poden accedir i servir qualsevol contingut d'usuari dins de la ret recuperant senyes formateados com a esquemes predefinits des de fluix de senyes federades a nivell de ret.

El protocol AT és la base de Bluesky, que es declara com una prova de concepte del protocol i pretén favorizar l'aparició d'un ecosistema de plataformes i servicis construïts sobre el Protocol AT, conegut com ATmosphere. Bluesky Social s'ha compromés a transferir el desenroll del protocol a un organisme d'estàndarts, com el Internet Engineering Task Force (IETF) en el futur.

Dissenye

L'objectiu del Protocol AT és crear un ecosistema en llínea descentralisat, interoperable i escalable a on els usuaris puguen conservar, gestionar i personalisar una única identitat en llínea federada a través de diverses plataformes i servicis en llínea. Bluesky Social descriu el protocol com un sistema "inspirat en la web oberta".

En comparació a atres protocols per a rets socials, com ActivityPub, a on les implementacions solen dissenyar-se com un servidor monolític que estaja tant les senyes de l'usuari com l'aplicació, el Protocol AT dividix estos elements en microservicios més chicotets que poden utilisar-se segons les necessitats específiques.

Els clients i servicis del Protocol AT interoperan per mig d'una API HTTP cridada XRPC, que utilisa principalment JSON per a la serialisació de senyes. Ademés, totes les senyes dins del protocol que deuen ser autenticados, referenciados o almagasenats estan codificats en CBOR, un format binari eficient dissenyat per a senyes estructurades.

Identitat de l'usuari

El protocol AT utilisa un sistema d'identificació doble: un identificador mutable basat en un nomene de domini (handle) i un identificador descentralisat (DID) immutable. Els noms de domini servixen com a identificadors per als usuaris i es verifiquen per mig de la consulta dels registres de recursos d'un domini. Els DIDs es resolen en documents DID, els quals contenen referències a metadatos clau de l'usuari, com el domini, les claus públiques i el repositori de senyes.

Els servicis poden assignar handles a nous usuaris en registrar-se, utilisant subdominis (per eixemple, usuari. bsky. social). Alternativament, els usuaris poden configurar un domini o subdomini personalisat com el seu handle (per eixemple, usuari. com o usuari. wikipedia. org), afegint un registre TXT als registres del domini o responent a solicituts HTTP en una URL específica del tipo . well-known, associant aixina el domini o subdomini en el DID de l'usuari.

El sistema de doble identificador del protocol proporciona tant identificadors fàcils d'usar per als servicis de cara a l'usuari com a identitats criptogràfiques consistents dins del protocol, al mateix temps que implementa un robust mecanisme de verificació de contes basat en TCP/IP a nivell del protocol.

Repositoris de senyes de l'usuari

Les senyes d'usuari dins del protocol s'almagasenen en repositoris de senyes dedicades, o repos. Cada usuari està associat a un únic repositori, sobre el qual té drets exclusius de gestió. Els repositoris contenen coleccions mutables de registres d'usuari, que registren accions com a publicacions, "m'agrada", seguiments i bloquejos. Els registres són persistents i solament poden afegir-se o eliminar-se baix solicitut explícita de l'usuari.

Cada registre dins de la colecció d'un repositori rep una clau de registre única, utilisada pels agents de la ret per a referenciar registres dins del repositori d'un usuari. L'implementació actual de les claus de registre utilisa identificadors de marca temporal (timestamp identifiers, TID), que es deriven del moment de creació del registre.

Els repositoris almagasenen les coleccions en un arbre de busca Merkle, que organisa els registres de forma cronològica basant-se en la seua TID.

Els archius multimèdia, junt en els seus metadatos, tamany i tipo de mig, s'almagasenen per separat dels repositoris com blobs, un tipo de senyes binaris no estructurats, en el servidor amfitrió de l'usuari. Açò permet que els agents de la ret accedixquen i processen archius multimèdia arbitraris, independentment del seu esquema original o context de càrrega.

Servidors de Senyes Personals

Els Servidors de Senyes Personals (en inglés: Personal Data Servers, PDSes) estagen els repositoris dels usuaris junt en els seus archius multimèdia associats. També actuen com a punts d'accés a la ret per als usuaris, facilitant actualisacions de repositoris, respals, consultes de senyes i solicituts d'usuari.

Els clients de les plataformes accedixen al protocol en nom de l'usuari consultant el seu PDS, que a la seua volta obté les senyes solicitades d'atres servicis dins de la ret. Este disseny es diferencia d'ActivityPub, a on les interaccions del protocol i els servicis es gestionen per mig de servidors amfitrions monolítics. Ya que els events de la ret es resolen a través de l'infraestructura d'indexación a nivell de ret del protocol, els PDSes, per disseny, tenen un impacte llimitat en l'experiència de l'usuari.

El protocol AT priorisa la portabilitat de les senyes, permetent als usuaris realisar respals i migrar els seus repositoris i mijos associats sense pèrdua d'informació, inclús en cas d'enfrontar-se a un PDS advers. El disseny dels PDSes dins del protocol implica requisits computacionals mínims per a la seua operació, lo que permet a individus o grups eixecutar els seus propis PDSes sense necessitat de recursos significatius.

Encara que la majoria dels repositoris dels usuaris residixen en PDSes administrats per Bluesky, existixen numerosos PDSes independents dins de la ret.

Relays i el Firehose

Els relays (relés) són un component clau de l'infraestructura d'indexación del protocol, funcionant com els indexadores centrals dins de la ret. Els relays recorren la ret en obtindre contínuament actualisacions dels repositoris des dels PDSes, per a després agregar-les, indexar-les i reenviar-les en fluix de senyes a nivell de ret, coneguts colectivament com el firehose. Este firehose està disponible per a tots els agents de la ret i pot ser consumit per qualsevol servici dins de la mateixa.

Els relays poden optar per indexar la totalitat o solament una part de la ret. En eliminar la necessitat de rastrejar o almagasenar senyes d'usuari i proporcionar un fluix de senyes unificat, els relays simplifiquen el desenroll d'aplicacions i servicis en el protocol, ademés de reduir els seus costs operatius.

No obstant, els relays han segut criticats per ser el component més centralisat en el disseny del protocol, donat el seu paper pràcticament indispensable en la ret i la falta d'incentius clars per a operar un relay.

Vistes d'Aplicació

Les Vistes d'Aplicació (App Views), anàlogues als servicis actuals de rets socials, són plataformes i servicis d'usuari final dins del protocol que consumixen, processen i entreguen senyes des dels relays als clients d'usuari en resposta a consultes realisades des dels PDSes dels usuaris. Utilisen informació a nivell de ret provinent del firehose, com a publicacions, "m'agrada", seguiments i respostes, per a crear experiències personalisades dins dels seus clients.

El disseny de les vistes d'aplicació dins del protocol permet una àmplia varietat d'implementacions. Estes poden incloure sistemes d'invitació, algoritmes personalisats, clients alternatius, estratègies diverses de monetisació i moderació de contingut, aixina com servicis fora del protocol. A pesar d'estes diferències, totes les vistes d'aplicació operen a partir de les mateixes senyes proporcionades pel firehose. Esta arquitectura reduïx la càrrega computacional i els requisits d'almagasenament de les vistes d'aplicació, ademés d'evitar la dependència d'un únic servici, permetent als usuaris canviar fàcilment entre Apps Views mentres conserven les seues publicacions, seguiments, "m'agrada", entre uns atres.

La Vista d'Aplicació més gran del protocol actualment és Bluesky, encara que atres Vistes d'Aplicació, com WhiteWind (una plataforma de blogs de format llarc), Frontpage (un lloc web de notícies socials similar a Hacker News) i Smoke Signal (un servici de gestió de RSVP), també estan disponibles dins del protocol.

Lexicons

Totes les publicacions dins del Protocol AT seguixen un llenguage global d'esquemes específic cridat lexicon, dissenyat per a admetre diferents modalitats de servicis i plataformes. Les vistes d'aplicació dins del protocol tenen la flexibilitat de definir els seus propis lexicons únics o utilisar els ya existents.

Este enfocament permet a les vistes d'aplicació crear lexicons personalisats adaptats als seus casos d'us específics, mantenint al mateix temps la compatibilitat en la ret en general. Per eixemple, els registres mostrats en una vistes d'aplicació enfocada en microblogging provablement usarien un lexicon diferent al d'una enfocada en compartir videos, ya que els tipos de contingut requerixen diferents conjunts d'atributs.

No obstant, les vistes d'aplicació també poden optar per servir contingut utilisant lexicons definits per atres vistes d'aplicació, inclús si el contingut es va publicar originalment en un atre lloc de la ret. Per eixemple, una nova vistes d'aplicació de microblogging podria elegir servir contingut prèviament publicat utilisant el lexicon definit per un competidor establit, lo que els permet oferir característiques i servicis nous mentres mantenen la compatibilitat en el contingut existent.

Este disseny d'esquemes està pensat per a eliminar la dependència d'un únic servici (user lock-in) i fomentar l'innovació centrada en l'usuari, obligant a les vistes d'aplicació a diferenciar-se per mig d'experiències úniques i funcionalitats adicionals, en lloc de basar-se en l'accés exclusiu al contingut.

Els lexicons es referencian dins dels registres utilisant Identificadors en Espais de Noms (Namespaced Identifiers, NSIDs), que consistixen en una autoritat de domini en orde invers al del nom de domini, seguida d'un segment de nom arbitrari. Per eixemple, com. appview. foo és un NSID vàlit, a on com. appview és l'autoritat de domini i foo és el segment de nom.

El lexicon més popular dins del protocol, app. bsky, definix l'esquema de microblogging de Bluesky.

Etiquetadores

Els etiquetadores (labelers) generen juïns sobre contingut generat per usuaris, com l'identificació de spam o material inapropiat. Estes etiquetes poden aplicar-se a diversos aspectes de la ret, incloent publicacions, imàgens o contes. El resultat produït per les etiquetes és consumit per les vistes d'aplicació i els PDSes, que a la seua volta poden oferir als usuaris diferents estratègies per a gestionar el contingut etiquetat, com ocultar-ho, etiquetar-ho visualment o desenfocarlo.

Bluesky Social ha publicat com còdic obert el seu servici intern de moderació per mig de etiquetadores, cridat "Ozone", lo que permet als usuaris crear servicis de moderació personalisats per a la ret.

Encara que els etiquetadores poden utilisar-se com un servici de moderació, també poden tindre fins informatius o d'entreteniment, com etiquetar temes de publicacions, pronoms dels usuaris o agregar etiquetes positives o lúdiques a perfils i publicacions.

Generadors de Feeds

Els Generadors de Feeds (Feed Generators) processen publicacions dins del firehose per a incloure-les en feeds personalisats. Despuix d'una consulta des d'un PDS, tornen una llista d'identificadors de publicacions (post IDs) a la vistes d'aplicació de l'usuari, que després pot utilisar-els per a crear feeds curats.

Adopció

l'implementació de referència del protocol es va llançar per primera volta en GitHub el 4 de maig de 2022 baix el nom Authenticated Data Experiment (ADX), i està llicenciada baix les llicencies MIT i Apache. En octubre de 2022, va passar a cridar-se Protocol AT.

El Protocol AT ha segut adoptat per al seu us per la ret social Bluesky, i és la seua implementació més popular. La pròpia ret social va obrir la federació en atres Servidors de Senyes Personals (Personal Data Servers) a finals de febrer de 2024, ya que originalment es va llançar sense la capacitat de federar-se en atres servidors que no estigueren gestionats per Bluesky Social. Ademés, el agregador de notícies Flipboard permet als usuaris iniciar sessió en el seu conte de Bluesky per a vore i interactuar en publicacions del servici.

Per a fomentar la seua adopció, Bluesky Social finança diversos proyectes que utilisen el Protocol AT per a federar-se o crear contingut a través de subvencions. Una aplicació notable finançada per estes subvencions és un servidor proxy conegut com SkyBridge, que pot convertir les cridades API de les aplicacions de Mastodon als seus equivalents en les APIs del Protocol AT/Bluesky, permetent als usuaris accedir a abdós rets, inclús sense soport oficial.

Encara que el Protocol AT és un protocol independent sense grans similituts tècniques en atres protocols, s'han desenrollat servicis que permeten interconectar contingut entre protocols. Un eixemple és el software Bridgy Fed, que permet publicar contingut entre ActivityPub i el Protocol AT. Les publicacions de Nostr també poden ser "doblement puenteades" al Protocol AT per mig d'un atre pont que permet publicar notes de Nostr a ActivityPub.