AT Protocol

Das AT Protocol (Authenticated Transfer Protocol, kurz auch atproto; englisch für Authentifiziertes Übertragungsprotokoll) ist ein Netzwerkprotokoll und offener Standard zum Beitreiben von föderierten sozialen Netzwerken. Es wird aktuell vom gemeinnützigen Unternehmen Bluesky PBLLC entwickelt, einer Public Benefit Corporation, die ursprünglich als unabhängige Forschungsgruppe von Twitter gegründet wurde, um die Möglichkeit von Dezentralisierung zu untersuchen. Außerdem wird der gleichnamige Kurznachrichtendienst Bluesky mit dem AT Protocol betrieben.

AT Protocol
Einführung:	18. Oktober 2022
Entwickler:	Bluesky PBC

Das Protokoll wurde entwickelt, um wahrgenommene Probleme im technischen Design anderer dezentraler Protokolle wie die Mitnahme von Nutzerdaten und dem persönlichen sozialen Netzwerk sowie auch Platforminteroperabilität und anpassbare Inhaltsalgorithmen zu lösen. Bluesky Social hat ebenfalls laut CEO Jay Graber versprochen, die Entwicklung des Protokolls in Zukunft an eine Normungsorganisation wie die IETF zu übergeben.

Design

Ein Diagramm der AT Protocol Föderationsarchitektur. Stand: Februar 2024.

Das AT Protocol verfolgt das Ziel, ein dezentralisiertes, interoperables und skalierbares Onlineökosystem zu etablieren, wo Nutzer eine einzelne föderierte Internetidentität über verschiedene Plattformen und Dienste hinaus benutzen und verwalten kann. Das Design des Protokolls priorisiert Entdeckbarkeit und, eine integrierte, anpassbare, benutzerorientierte Erfahrung zu bieten. Bluesky Social beschreibt das Protokoll selbst als „dem offenen Internet nachempfunden“.

Verglichen mit anderen Protokollen für soziale Netzwerke wie ActivityPub, welche typischerweise als ein monolithischer Server entworfen sind, der sowohl Nutzerdaten als auch die Anwendung enthält, teilt das AT Protocol diese Elemente in kleinere, teils optionale Microservices auf.

Sowohl Dienste als auch clientseitige Anwendungen nutzen eine Programmierschnittstelle basierend auf HTTP names XRPC für Interoperabilität. Die Schnittstelle empfängt Daten hauptsächlich im JSON Format.

Nutzeridentität

Das AT Protocol verwendet ein zweifaches Identitätssystem: ein veränderbarer Alias durch eine Domain und eine einzigartige dezentralisierte Kennung (decentralized identifier, DID). Aliasse dienen als Erkennungszeichen für Endnutzer und werden verifiziert, indem die Records der Domain abgefragt werden. DIDs werden zu DID Dokumenten aufgelöst, welche die Referenzen zu Schlüssel-Metadaten, wie den Alias des Nutzer, den öffentlichen Schlüssel und Datenrepository, enthalten.

Dienste können neuen Nutzern bei der ersten Anmeldung Aliasse mit Hilfe von Subdomains (z. B. @nutzername.bsky.social) zuweisen. Alternativ kann ein Nutzer eine eigene Domain oder Subdomain als ihren Alias Konfigurieren (z. B. @nutzername.com or @nutzername.wikipedia.org), indem ein TXT-Record zu den Records der Domain hinzugefügt wird, die die Domain mit der DID des Nutzers assoziiert.

Die Identitätsinfrastruktur des AT Protocol.

Das zweifache Identitätssystem erlaubt sowohl nutzerfreundliche Identifizierung zur Nutzung in Diensten für Endbenutzer und gleich bleibende kryptographische Identitäten innerhalb des Protokolls, während eine TCP/IP-basierte Kontoverifizierung auf Protokollebene möglich ist.

Nutzerdaten-Repositorys

Nutzerdaten sind im Protokoll in dedizierten Repositorys gespeichert. Jedes Nutzerkonto ist mit einem einzigen Repository assoziiert, über welches der Nutzer exklusive Verwaltungsrechte besitzt. Repositorys enthalten veränderbare Sammlungen von Einträgen, die Aktionen des jeweiligen Nutzers wie beispielsweise Posts und Likes sowie die Kennungen von gefolgten und blockierten Konten speichern. Einträge sind persistent und können nur auf explizierter Anfrage des Nutzers hinzugefügt oder entfernt werden.

Repositorys enthalten selbst keine Medien wie Bilder oder Videos, die vom Nutzer hochgeladen wurden, sondern speichern nur eine Referenz auf die assoziierten Mediendateien innerhalb des Servers.

Repositorys und deren assoziierte Medien wurden entworfen, um zwischen Host-Servern ohne Datenverlust verschoben zu werden, selbst wenn ein Host-Server sich entscheidet, gegen das Kerninteressen des Nutzers zu verstoßen, indem der Betreiber des Host-Servers zum Beispiel mutwillig Daten manipuliert oder den Host-Server ohne Datenübergabe nicht weiter betreibt. Nutzer können sich ebenfalls entscheiden, eine Sicherheitskopie ihres Repositorys und ihrer Medien auf einem zweiten Server zu speichern.

Personal Data Server

Personal Data Server (PDSes) speichern Nutzerdaten-Repositorys und deren assoziierte Medien. Sie dienen ebenfalls als Einstiegspunkt in das Netzwerk für Nutzer, indem sie Repositories aktualisieren, Backups anlegen, die Datenabfrage ermöglichen und technische Anfragen der Nutzer beantworten.

Nutzer greifen auf das Protokoll zu, indem sie ihre PDS anfragen. Die PDS laden falls nötig die angefragten Daten von anderen Diensten innerhalb des Netzwerks herunter und leiten sie an den Nutzer weiter. Dieses Design unterscheidet sich von ActivityPub, wo Interaktionen und Dienste typischerweise von einem einzigen Dienst angeboten verwaltet werden. Da Aktualisierungen der Repositorys durch die netzwerkweite Indizierungsinfrastruktur aufgelöst werden, sind PDS für das Nutzererlebnis großenteils unbedeutend.

Das Design der PDS im Protokoll hat die Folge, dass für den Betrieb von PDS nur niedriger Rechenbedarf nötig ist. Dies erlaubt Einzelpersonen oder Gruppen, ihre eigenen PDS kostengünstig zu betreiben.

Obwohl die meisten Nutzerdaten-Repositorys in PDS liegen, die von Bluesky Social betrieben werden, existieren mehrere unabhängige PDS im Netzwerk.

Relais und der Firehose

Relais sind eine Schlüsselkomponente der Indizierungsinfrastruktur des Protokolls, indem sie die grundlegende Indizierung innerhalb des Netzwerks sicherstellen. Relais durchsuchen kontinuierlich das Netzwerk und laden Aktualisierungen von Repositorys von PDS innerhalb des Netzwerks. Danach aggregieren, indizieren, und leiten sie diese Aktualisierungen in einem einzelnen, einheitlichen Datenstrom namens Firehose (englisch für Feuerwehrschlauch) weiter. Der Firehose ist allen Akteuren im Netzwerk zugänglich und kann durch jeden Dienst im Netzwerk verwendet werden. Relais können sich entscheiden, alle oder nur Teile des Netzwerks zu indizieren.

Relays vereinfachen die Entwicklung und reduzieren den rechnerischen Mehraufwand von Anwendungen und Diensten im Protokoll, indem sie effizienten Zugang zu Netzwerkaktualisierungen über den Firehose erlauben. Damit vermeiden sie die Notwendigkeit, dass Dienste Nutzerdaten zwangsweise speichern und eigenständig das Netzwerk indizieren müssen.

Relays stehen in der Kritik, die zentralisierteste Einheit des Protokolls zu sein, da sie für die Nutzung des Netzwerks notwendig sind, aber eine sehr hohe Rechenanforderung aufweisen und es keine klaren Anreize gibt, ein Relais zu betreiben. Bluesky Social betreibt derzeit alle bekannten Relais im Netzwerk.

App Views

App Views, analog zu heutigen sozialen Netzwerken, sind Plattformen für Endbenutzer und Dienste im Protokoll, die vom Relais auf Anfrage von dem PDS eines Nutzers erhaltene Daten benutzen, verarbeiten und ausliefern. Sie verwenden netzwerkweite Informationen der Firehose wie Postings, Likes und Antworten auf Postings, um ein individuelles Benutzererlebnis in ihren Clients zu erzielen.

Das Design von App Views im Protokoll erlaubt erhebliche Variationen in der Implementation. App Views können Einladungssysteme, benutzerdefinierte Algorithmen, verschiedene Monetarisierungsmodelle and Moderationsstrategien, and zusätzliche Dienste außerhalb des Protokolls. Trotz dieser Unterschiede arbeiten alle App Views mit denselben Daten, die aus dem Firehose stammen. Diese Architektur reduziert die Rechenlast und den Speicherbedarf der App-Ansichten und verhindert den Lock-in der Nutzer, indem sie es ihnen ermöglicht, einfach zwischen den App-Ansichten zu wechseln und dabei ihre Beiträge, Follower, Likes usw. beizubehalten.

Der größte App View des Protokolls ist derzeit Bluesky, wobei anderer App Views wie WhiteWind (eine Blogplatform) und Smoke Signal (ein Termineinladungsverwaltungssystem) auch verfügbar sind.

Lexicons

Alle Postings im Protokoll folgen einem spezifischen Schema, das Lexicon (englisch für Lexikon) genannt wird, um verschiedene Modalitäten eines sozialen Medium abzubilden. Zum Beispiel würde ein App View für Microblogging ein anderes Lexicon verwenden als ein App View für Langformat-Video, da die Inhalte unterschiedliche Attribute tragen.

App Views haben die Flexibilität, entweder ein eigenes Lexicon für ihren Dienst zu definieren oder Inhalte aus einem oder mehreren bestehenden Lexicons bereitzustellen. Dieser Ansatz erlaubt App Views, eigene zu den angebotenen Diensten passende Lexicons zu entwerfen, während sie Kompatibilität mit dem breiteren Netzwerk erhalten. Außerdem können App Views vordefinierte Lexicons verwenden, um Inhalte anzuzeigen, die bereits im Netzwerk verfügbar sind, auch wenn sie ursprünglich über einen anderen App View erstellt wurden.

Das am meisten verwendete Lexicon im Protokoll, app.bsky, definiert das Microbloggingschema von Bluesky.

Meinungsbezogene Dienste

Meinungsbezogene Dienste (englisch opinionated services) sind Dienste, die im Protokoll Daten nach subjektivem Ermessen für die Zwecke von Inhaltsmoderation oder -gestaltung von dem Firehose verarbeiten und anbieten. Diese Dienste stehen im Kontrast zu der objektiven Natur von Relais und App Views. Meinungsbezogene Dienste erlauben es Nutzern, ihren Inhaltskonsum und ihre Moderationspräferenzen anzupassen, während die Neutralität der Kerndienste des Protokoll gewahrt bleibt.

Nutzer haben die Möglichkeit, Dienste jederzeit über ihren Client zu (de)abonnieren. Ausgenommen davon sind im aktuellen App View festgeschriebene Dienste wie dem standardmäßigen Moderationsdienst, der von Bluesky angeboten wird. Die Modularität dieser Dienste ermöglicht einen anpassbaren, stapelbaren, nutzerzentrierten Ansatz für die Kuratierung und Moderation von Inhalten innerhalb des Protokolls.

Kennzeichner

Kennzeichner (englisch labeller) kategorisieren Nutzer und ihre Inhalte, zum Beispiel als Spam oder unangemessene Inhalte. Diese Kennzeichnungen können auf verschiedene Aspekte innerhalb des Netzwerks, inklusive Postings, Bilder oder Nutzerkonten angewendet werden. Die Entscheidungen von Kennzeichnern werden von App Views und PDS aufgenommen, welche damit verschiedene Strategien für Nutzer anbieten können, die gekennzeichneten Inhalte beispielsweise zu verstecken, unkenntlich zu machen oder komplett zu verstecken.

Feederzeuger

Feederzeuger verarbeiten Postings aus dem Firehose, um sie in benutzerdefinierten Feeds anzuzeigen. Sie geben eine Liste von Postings an den App View des Nutzers, welche dort verwendet werden können, um diese Feeds zu kuratieren.

Annahme

Die Referenzimplementierung des Protokolls wurde zuerst am 4. Mai 2022 auf GitHub unter dem Namen Authenticated Data Experiment (ADX) veröffentlicht und ist sowohl unter der MIT als auch der Apache-Lizenz verfügbar. Im Oktober 2022 wurde es in AT Protocol umbenannt.

Das AT Protocol wird von dem sozialen Netzwerk Bluesky (ebenfalls von Bluesky Social PBC entwickelt) eingesetzt. Nachdem das soziale Netzwerk ohne Fähigkeit zur Föderation veröffentlicht wurde, erlaubt es seit Ende Februar 2024 die Föderation mit anderen Personal Data Servern. Außerdem erlaubt der Nachrichtenaggregator Flipboard, dass sich Nutzer mit ihrem Bluesky Nutzerkonto anmelden, um Nachrichten auf dem Dienst anzuschauen und mit ihnen zu interagieren. Um der Annahme des Protokolls zu helfen, hat Bluesky Social mehrere Projekte, die das AT Protocol für Föderation oder Inhaltserstellung verwenden, finanziell gefördert. Eine nennenswerte Anwendung, die gefördert wurde, ist ein Proxy bekannt als SkyBridge, der API-Anfragen von Mastodon Anwendungen in äquivalente AT Protocol Anfragen übersetzen kann. Dies erlaubt Nutzen Zugang zu beiden Netzwerken ohne, dass dies offiziell unterstützt ist.

Obwohl das AT Protokoll keine bedeutenden technischen Ähnlichkeiten zu anderen Protokollen aufweist, wurden mehrere Dienste entwickelt, die Inhalte zwischen verschiedenen Protokollen überbrücken können. Ein Beispiel ist Bridgy Fed, das Inhalte zwischen ActivityPub und dem AT Protocol crossposten kann. Inhalte von Nostr können ebenso doppelt überbrückt werden, so dass Crossposts sowohl vom AT Protocol nach Nostr und umgekehrt erstellt werden können.

Siehe auch

• ActivityPub, ein alternatives Protokoll, das Dienste wie Mastodon betreibt
• Nostr, ein ähnliches Protokoll für soziale Netzwerke

Literatur

• Bluesky and the AT Protocol: Usable Decentralized Social Media (2024)
• “I’m in the Bluesky Tonight”: Insights from a Year Worth of Social Data (2024)

Weblinks

• Offizielle Website und Dokumentation
• Bluesky API Dokumentation
• atproto auf GitHub