AT Protocol

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

 

AT Protocol
Logo des AT Protocol. Es zeigt ein At-Zeichen gefärbt mit einem Bild eines blauen Himmels.
Einführung: 18. Oktober 2022
Entwickler: Bluesky PBC

Das AT Protocol (Authenticated Transfer Protocol, kurz auch atproto; englisch für Authentifiziertes Übertragungsprotokoll)[1][2] ist ein Protokoll und offener Standard zum Beitreiben von föderierten sozialen Netzwerken.[3] Es wird aktuell von Bluesky Social PBC 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.[4] Außerdem wird der gleichnamige Kurznachrichtendienst Bluesky mit dem AT Protocol betrieben.[5][6]

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.[7]

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“.[8]

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.[9]

Nutzeridentität

[Bearbeiten | Quelltext bearbeiten]

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.[10]

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.[11]

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

[Bearbeiten | Quelltext bearbeiten]

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.[12]

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.[13]

Personal Data Server

[Bearbeiten | Quelltext bearbeiten]

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.[8]

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.[14]

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.[15]

Relais und der Firehose

[Bearbeiten | Quelltext bearbeiten]

Relais sind eine Schlüsselkomponente der Indizierungsinfrastruktur des Protokolls, indem sie die grundlegende Indizierung innerhalb des Netzwerks sicherstellen.[8] 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.[16] 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.[8]

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.[17]

Rails 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.[18][19]

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.[20] 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.[21]

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.[22][23]

Alle Postings im Protokoll folgen einem spezifischen Schema, das Lexicon (englisch für Lexikon) genannt wird, um verschiedene Modalitäten eines sozialen Medium abzubilden.[24] 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.[25] Dieser Ansatz erlaubt App Views, eigene zu den angebotenen Diensten passende Lexikons 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.[26]

Das am meisten verwendetste Lexicon im Protokoll, app.bsky, definiert das Microblogging schema von Bluesky.[25]

Meinungsbezogene Dienste

[Bearbeiten | Quelltext bearbeiten]

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.[20] Die Modularität dieser Dienste ermöglicht einen anpassbaren, stapelbaren, nutzerzentrierten Ansatz für die Kuratierung und Moderation von Inhalten innerhalb des Protokolls.[27]

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.[28]

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.[29]

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.[30] Im Oktober 2022 wurde es in AT Protocol umbenannt.[31]

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.[32] 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.[33] 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.[34] 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.[35]

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.[36][37] 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.[38]

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

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. The AT Protocol. In: Bluesky. Abgerufen am 30. Juli 2024 (englisch).
  2. Building on the AT Protocol. In: Bluesky. 11. Oktober 2023, abgerufen am 5. September 2024 (englisch).
  3. Martin Kleppmann, Paul Frazee, Jake Gold, Jay Graber, Daniel Holmgren, Devin Ivy, Jeromy Johnson, Bryan Newbold, Jaz Volpert: Bluesky and the AT Protocol: Usable Decentralized Social Media. 5. Februar 2024, abgerufen am 6. September 2024 (englisch).
  4. Adi Robertson: Will Elon Musk keep funding Twitter's most interesting side project? In: The Verge. 29. Oktober 2022, abgerufen am 31. Juli 2024 (englisch).
  5. Adi Robertson: Twitter is funding research into a decentralized version of its platform. In: The Verge. 11. Dezember 2019, abgerufen am 30. Juli 2024 (englisch).
  6. Kate Conger: Twitter Wants to Reinvent Itself, by Merging the Old With the New. In: The New York Times. 2. März 2022, ISSN 0362-4331 (englisch, nytimes.com [abgerufen am 31. Juli 2024]).
  7. Nilay Patel: Bluesky CEO Jay Graber on breaking free from Twitter and competing with Threads and Mastodon. In: The Verge. 25. März 2024, abgerufen am 4. August 2024 (englisch).
  8. a b c d Federation Architecture. In: Bluesky. Abgerufen am 5. September 2024 (englisch).
  9. HTTP API (XRPC). In: AT Protocol. Abgerufen am 5. September 2024 (englisch).
  10. Identity. In: AT Protocol. Abgerufen am 5. September 2024 (englisch).
  11. Domain Names as Handles in Bluesky. In: Bluesky. Abgerufen am 5. September 2024 (englisch).
  12. Personal Data Repositories. In: AT Protocol. Abgerufen am 5. September 2024 (englisch).
  13. Repository. In: AT Protocol. Abgerufen am 5. September 2024 (englisch).
  14. PDS Entryway. In: Bluesky. Abgerufen am 5. September 2024 (englisch).
  15. 2024 Protocol Roadmap. In: Bluesky. 6. Mai 2024, abgerufen am 5. September 2024 (englisch).
  16. Firehose. In: Bluesky. Abgerufen am 5. September 2024 (englisch).
  17. The AT Protocol Developer Ecosystem. In: Bluesky. Abgerufen am 5. September 2024 (englisch).
  18. AT Protocol - First Thoughts - Rusted Gears - Obsidian Publish. In: publish.obsidian.md. Abgerufen am 5. September 2024 (englisch).
  19. Rory Mir, Ross Schulman: What’s the Difference Between Mastodon, Bluesky, and Threads? In: Electronic Frontier Foundation. 18. Juni 2024, abgerufen am 5. September 2024 (englisch).
  20. a b Moderation in a Public Commons. In: Bluesky. Abgerufen am 5. September 2024 (englisch).
  21. What is Bluesky? In: Bluesky. Abgerufen am 5. September 2024 (englisch).
  22. WhiteWind atproto blog. In: WhiteWind blog. Abgerufen am 5. September 2024 (englisch).
  23. Why atprotocol? In: Smoke Signal. Abgerufen am 5. September 2024 (englisch).
  24. Protocol Overview. In: AT Protocol. Abgerufen am 5. September 2024 (englisch).
  25. a b Lexicon. In: AT Protocol. Abgerufen am 5. September 2024 (englisch).
  26. Bluesky: An Open Social Web. In: Bluesky. Abgerufen am 5. September 2024 (englisch).
  27. Bluesky’s Stackable Approach to Moderation. In: Bluesky. Abgerufen am 5. September 2024 (englisch).
  28. Labeling and Moderation Controls. In: GitHub. Abgerufen am 5. September 2024 (englisch).
  29. Custom Feeds. In: Bluesky. Abgerufen am 5. September 2024 (englisch).
  30. Adi Robertson: Twitter's decentralized, open-source offshoot just released its first code. In: The Verge. 4. Mai 2022, abgerufen am 31. Juli 2024 (englisch).
  31. David Pierce: Bluesky built a decentralized protocol for Twitter — and is working on an app that uses it. In: The Verge. 19. Oktober 2022, abgerufen am 4. August 2024 (englisch).
  32. Amrita Khalid: Bluesky starts letting users host their own servers. In: The Verge. 22. Februar 2024, abgerufen am 4. August 2024 (englisch).
  33. Wes Davis: Flipboard is ready to work with Bluesky and Pixelfed. In: The Verge. 23. Mai 2023, abgerufen am 1. August 2024 (englisch).
  34. Sarah Perez: Bluesky is funding developer projects to give its Twitter/X alternative a boost. In: TechCrunch. 11. März 2024, abgerufen am 1. August 2024 (englisch).
  35. Sarah Perez: Bluesky backs a project that would let Mastodon apps, like Ivory, work with its network. In: TechCrunch. 25. April 2024, abgerufen am 9. August 2024 (englisch).
  36. Sarah Perez: Bluesky and Mastodon users can now talk to each other with Bridgy Fed. In: TechCrunch. 5. Juni 2024, abgerufen am 4. August 2024 (englisch).
  37. Amanda Silberling: Bluesky and Mastodon users are having a fight that could shape the next generation of social media. In: TechCrunch. 14. Februar 2024, abgerufen am 4. August 2024 (englisch).
  38. Sarah Perez: The 'vote Trump' spam that hit Bluesky in May came from decentralized rival Nostr. In: TechCrunch. 21. Mai 2024, abgerufen am 4. August 2024 (englisch).