Wo befindet sich at://?

• Das AT-Protokoll ist das grundlegende Protokoll für dezentrale soziale Netzwerke, und alle Daten werden durch at://-URIs identifiziert
• Ein at://-URI verwendet den Ersteller (Nutzer) der Daten als Authority; wo diese Daten tatsächlich gehostet werden, muss separat ermittelt werden
• Die URI-Auflösung erfolgt in drei Schritten: Handle in eine Identität (DID) umwandeln, per DID-Dokument den Hosting-Server ermitteln und anschließend auf diesem Server die JSON-Daten anfordern
• Es werden zwei DID-Arten (did:web, did:plc) unterstützt, die sich jeweils in Vor- und Nachteilen sowie der Art der Datenbewahrung unterscheiden
• Dieser Ansatz betont, dass die Datenhoheit beim Nutzer liegt, und gewährleistet Persistenz, sodass die Verknüpfung erhalten bleibt, auch wenn sich Handle oder Hosting ändern

---

Das AT-Protokoll, at://-URIs und der Prozess der Identitätsauflösung sozialer Daten

# Grundstruktur des AT-Protokolls und von at://-URIs

• Das AT-Protokoll sorgt dafür, dass verteilte Server nach einem bestimmten Standard miteinander kommunizieren; dieses gesamte Ökosystem wird als „atmosphere“ bezeichnet
• Jedes Datum innerhalb der atmosphere erhält einen eindeutigen URI, der mit at:// beginnt; dieser URI fungiert gewissermaßen als Link auf JSON-Daten
• Anders als bei traditionellen URI-Strukturen wird im AT-Protokoll der Ersteller (Nutzer) der Daten als Authority des URI gesetzt
  • In der Form at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z gibt ruuuuu.de beispielsweise an, wem die betreffenden Daten gehören
• Der physische Server, auf dem die Daten tatsächlich gehostet werden, ist nicht direkt im URI enthalten; um ihn zu finden, ist ein zusätzlicher Auflösungsprozess nötig

# Die drei Schritte der Auflösung eines at://-URI

• Um einen at://-URI auf die tatsächlichen Daten (JSON) abzubilden, sind drei Schritte nötig
  1. Das Handle (ruuuuu.de usw.) in eine Identität (DID: Decentralized Identifier) umwandeln
     • Das Handle ist ein Alias zur Nutzeridentifikation und kann sich ändern
     • Daher muss es in eine unveränderliche globale ID, eine DID, umgewandelt werden
     • Umwandlungsmethoden:
       • DNS-TXT-Record für _atproto.<Handle> abfragen → Wert did=... prüfen
       • oder https://<Handle>/.well-known/atproto-did aufrufen
  2. Über das DID-Dokument die Hosting-Informationen der Daten ermitteln
     • Das DID-Dokument enthält Informationen wie den öffentlichen Schlüssel dieser Identität und Service-Endpunkte (Server)
     • Bei did:web:~ erfolgt der Zugriff domänenbasiert (https://Domain/.well-known/did.json)
     • Bei did:plc:~ erfolgt die Abfrage über das PLC-Verzeichnis (https://plc.directory/DID)
     • Der Service-Endpunkt (serviceEndpoint) ist der Server, auf dem die Daten tatsächlich gehostet werden
  3. Die JSON-Daten über die API des Hosting-Servers anfordern
     • An den Endpunkt com.atproto.repo.getRecord werden die jeweiligen Bestandteile von at:// als Parameter übergeben, um die Daten anzufordern
     • Das zurückgegebene JSON sind die tatsächlichen Daten, die dem at://-URI zugeordnet sind

# Erläuterung des Auflösungsprozesses anhand eines Beispiels

• Beispiel: at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z
  • Schritt 1: ruuuuu.de → did:web:iam.ruuuuu.de (über DNS-TXT-Record oder .well-known prüfen)
  • Schritt 2: DID-Dokument unter https://iam.ruuuuu.de/.well-known/did.json abrufen → serviceEndpoint ist https://blacksky.app
  • Schritt 3: Anfrage an https://blacksky.app/xrpc/com.atproto.repo.getRecord?... → tatsächliches JSON wird zurückgegeben

    {
      "uri": "at://did:web:iam.ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z",
      "cid": "...",
      "value": {
        "text": "posting from did:web, like a boss",
        "$type": "app.bsky.feed.post",
        ...
      }
    }
    

• Selbst wenn sich das Handle ändert, bleibt die Verknüpfung zwischen Konto und Daten erhalten, wenn ein DID-basierter at://-URI (Permalink) verwendet wird

# Unterschiede zwischen den DID-Arten did:web und did:plc

• did:web:
  • Man kann die eigene Domain selbst verwalten und verifizieren
  • Geht die Kontrolle über die Domain verloren, besteht die Gefahr, die gesamte ID zu verlieren
• did:plc:
  • Die PLC (Public Ledger of Credentials) ist die Instanz, die die ID verwaltet
  • Die ID ist nicht an eine Domain gebunden, allerdings besteht die Möglichkeit eingeschränkter Kontrolle, etwa wenn der PLC-Betreiber Updates verweigert
  • Sämtliche Änderungsverläufe können per Hash verifiziert und nachverfolgt werden

# Trennung von Identität, Hosting und Daten sowie Persistenz

• at:// trennt Identität und Daten-Hosting, wodurch Nutzerdaten portabel werden und dauerhafte Links entstehen können
• Das Handle (Alias) kann jederzeit geändert werden, und auch der Hosting-Server kann entsprechend umziehen
• Die DID (Identität) bleibt unveränderlich; darauf basierende at://-URIs können als persistente Permalinks genutzt werden
• Das DID-Dokument enthält Eigentumsnachweise für das Handle, Schlüssel zur Signaturprüfung und Hosting-Informationen und gewährleistet damit Vertrauen und Flexibilität

# Praktische Anwendung und Hinweise für Entwickler

• In der Praxis empfangen die meisten AT-basierten Apps Daten per Push, etwa über WebSocket, und aggregieren sie in einer internen Datenbank
• Dennoch ist das Verständnis der Auflösung von at://-URIs unerlässlich, um die Netzwerkeigenschaften zu verstehen und Datenportabilität sicherzustellen
• Das at://-System legt eine soziale Netzwerkabstraktion über HTTP, DNS und JSON und setzt Datenhoheit beim Nutzer technisch um

# Fazit

• Das AT-Protokoll und at://-URIs entwickeln Identität, Verknüpfbarkeit und Persistenz sozialer Daten technisch deutlich weiter
• Entwickler sollten den zentralen Workflow beherrschen, darunter Handle-Auflösung, Nutzung von DIDs, die Struktur von DID-Dokumenten und die tatsächliche Datenabfrage
• Dank dieser Struktur lassen sich Flexibilität und Eigentum in Bezug auf die eigenen Inhalte, die Identität und den Hosting-Ort gewinnen

[GN⁺]

Hacker-News-Kommentare

• Ich habe mich, inspiriert von den jüngsten Artikeln über ATProto, bei bsky angemeldet, aber ich sehe nur endlose US-Politik. Selbst wenn ich ständig auf „Weniger davon anzeigen“ klicke, bringt das kaum etwas. Ich frage mich, ob das einfach die Natur dieser Plattform ist. Es ist mental ziemlich unerquicklich, ständig nur offensichtliche Meinungen zu irgendwelchen seltsamen Debatten im Ausland zu sehen.

  • Bei neuen Accounts ist der „Discover“-Feed ziemlich schlecht. Wenn sich Likes und Follow-Daten ansammeln, wird er allmählich besser, aber immer noch nicht wirklich gut. Ich persönlich empfehle den „For You“-Feed. Dort werden Likes schnell berücksichtigt und zufällige Inhalte weniger stark gepusht. Der „Dev Trending“-Feed ist auch ziemlich gut: For You Feed, Dev Trending
  • Ich bin so vorgegangen, dass ich ein paar vernünftige Accounts gefunden und ihnen gefolgt bin und den „Discovery“-Tab komplett ausgeblendet habe. Danach habe ich anhand der Interaktionen von Leuten aus meinen Followern/Follows meine Follow-Liste nach und nach natürlich erweitert. Oder ich habe Accounts auf Blogs oder Websites gefunden und ihnen dort gefolgt. Meiner Meinung nach funktioniert Social Media so wirklich sozial, und ich mag es nicht, automatisch empfohlene Inhalte aufgezwungen zu bekommen.
  • Zum Glück hat bsky einen nicht-algorithmischen Feed, der nur die Beiträge der Accounts zeigt, denen man folgt. Ich glaube, das ist die einzige Möglichkeit, geistig gesund zu bleiben.
  • Ich habe bsky über ein Jahr lang benutzt, aber der Großteil der Inhalte war US-Politik. Für mich als Europäer ist das einfach nur Rauschen. Deshalb bin ich wieder zu Mastodon zurückgegangen. Um Leuten aus der Tech-Szene zu folgen, war Mastodon viel besser. Nachrichten bekomme ich ohnehin komplett per RSS in feedly. Ich weiß inzwischen nicht mehr, wozu ich Bluesky brauche. Es wirkt einfach wie die linke Version von Twitter. Die Technologie war als weiterentwickelte Form von Nostr interessant, aber das war’s auch.
  • Ich empfehle, in die Einstellungen zu gehen und unter Contents and Media > Your Interests > News and Politics den entsprechenden Punkt auszuschalten. Falls du nur Nachrichten und Politik aus anderen Ländern als den USA sehen willst, kenne ich leider keine gute Methode.

• Ich bin mir immer noch nicht sicher, ob dieses Projekt die Fragen von Identität und Dateneigentum wirklich sinnvoll löst. Beim Thema Identität läuft es im Grunde darauf hinaus, entweder die eigene Domain oder die Domain eines anderen zu verwenden, etwa die von Bluesky. Die meisten Menschen haben keine eigene Domain, also gehört ihre Identität letztlich einem Dritten. Mit den Daten ist es genauso. Wenn ein Account bei Bluesky oder auf einem anderen Server gesperrt wird, wird auch der Speicher geschlossen, und man verliert sogar die Chance, die Daten anderswohin zu übertragen. Das ist genau wie bei E-Mail. Wenn man keine eigene Domain und keinen eigenen Server hat, kontrolliert man faktisch gar nichts.

  • Bei AT sind Daten nicht an Handle oder Hosting gebunden, sondern an die DID (Decentralized Identifier, dezentrale Identität). In meinem Beitrag habe ich das näher erläutert. Selbst wenn du die „Handle“-Domain verlierst, wird im Grunde nur das Handle ungültig, und in der App steht statt des Benutzernamens etwa „invalid handle“. Beiträge, Follower und andere Daten bleiben erhalten, weil sie über die DID abrufbar sind. Das Handle ist nur ein Spitzname. Man kann es auch über die Funktion „Handle ändern“ in der App wechseln. Beim Hosting ist es ähnlich: Mit einem Repository-Backup kann man den Speicher — trotz gewisser Hürden — an einen anderen Ort umziehen. Man kann Backups auch automatisieren, und es gibt bereits Third-Party-Apps, die das automatisch machen. In der offiziellen Bluesky-App kann man das Repository ebenfalls exportieren. Wenn der Hosting-Anbieter kooperativ ist, gibt es Fälle wie PDSMover. Und selbst wenn nicht, zeigt adversarial pds migration, dass es möglich ist. Derzeit braucht man dafür noch technisches Wissen, aber ich hoffe, dass dieser Prozess irgendwann einfacher wird. Wenn man das Repository auf einen neuen Host hochlädt, bekommt man unter derselben Identität wieder alle Beiträge, Follower usw. zurück, ohne Unterschied zum vorherigen Zustand. Das ist sehr anders als bei E-Mail. Im Moment ist es etwas schwierig, aber mit der Weiterentwicklung des AT-Ökosystems dürfte es deutlich komfortabler werden.
  • Selbst wenn man eine Domain besitzt, kann man sie irgendwann verlieren. Anders als Server hängen Domains von Registraren ab und wirken deshalb anfälliger. Deshalb habe ich meinen Registrar gezielt in meinem eigenen Rechtsraum gewählt, damit ich im Problemfall etwas mehr Hoffnung auf Wiederherstellung habe.
  • Die Mehrheit der Nutzer ohne eigene Domain ist immer dem Risiko ausgesetzt, dass der Hosting-Anbieter zum „Feind“ wird, etwa durch eine plötzliche Accountsperre. Vollständig schützen kann man sich letztlich nur, wenn man die Domain selbst unter einer neutralen TLD besitzt und den Traffic per DNS selbst steuert. Aber selbst unter diesen realen Bedingungen — dass fast niemand eine eigene Domain verwenden wird — ist dieses Projekt ein Fortschritt, weil es zumindest teilweise mehr Flexibilität und Schutz bietet, verglichen mit klassischen Big-Social-Plattformen wie Facebook, X oder Instagram, wo Daten auf ewig eingeschlossen bleiben. Bluesky scheint sich gerade deshalb dafür zu interessieren, weil man in so einem Umfeld das Handle behalten und nur das Daten-Hosting verlagern kann. Ich denke, die Branche erreicht Perfektion nicht auf einmal, sondern entwickelt sich weiter, indem sie reale Probleme schrittweise verbessert.
  • Der beste Nachweis von Identität ist meiner Meinung nach der Besitz eines privaten Schlüssels. Beim Hosting wäre BitTorrent vielleicht am robustesten. Man könnte Inhalte in ein git-Repository legen, Commits signieren und das Ganze per Torrent verteilen. Für Update-Benachrichtigungen habe ich an NNTP oder RSS gedacht. Das Problem wären Auffindbarkeit und fehlende Interaktion, also etwa keine Kommentare.
  • Immerhin kann man bei E-Mail PGP-/SMIME-Schlüssel mitnehmen und an einen anderen Ort übertragen. Ich frage mich, ob ATproto nicht ein ähnliches Konzept ist.

• Dans Erklärungen sind immer hervorragend, und das ist gerade jetzt passend, wo es Nachrichten darüber gibt, dass Bluesky die Kontrolle über PLC überträgt. Unser Team hat sich bei fair.pm ebenfalls für dasselbe DID-System entschieden, um WordPress-Plugins dezentral zu verteilen — im Grunde eine Art Paketverwaltung wie ein App Store. Die Bluesky-Seite, besonders Bryan, hat uns sehr geholfen, und wir haben sogar Unterstützung für Ed25519-Schlüssel bekommen, damit wir libsodium nutzen können. Unser Protokoll wird auf DID und Blueskys stackable moderation aufbauen, aber nicht direkt atproto verwenden. Wichtig ist, dass DID ein W3C-Standard ist und PLC deshalb nicht an atproto gebunden ist.

  • Wer ist „wir“, und wenn das ein Versuch ist, das WordPress-Drama technisch zu lösen, würde ich gern mehr Details hören.
  • Du sagst, PLC sei nicht an atproto gebunden, aber ist PLC als DID-Methode nicht letztlich trotzdem an Bluesky oder irgendeine zentrale Autorität gekoppelt? Wenn es so zentralisiert ist, warum nennt man es dann DID? did:plc ist auch nicht portabel. Warum hat man es nicht eher wie did:web formuliert und dabei PLC-ähnliches Verhalten ergänzt? Warum hat man die method-specific-id nicht etwa auf Basis eines Public-Key-Hashs portabel gemacht? Und warum nicht dezentraler über DHTs wie did:pkarr? PLC wirkt letztlich wie noch ein weiteres zentralistisches System.

• Um at:// aufzulösen, muss man eine GET-Anfrage an plc.directory senden, und an dieser Stelle scheint das System in ein zu 100 % zentralisiertes Modell zu kippen. Ich hätte mir zumindest gewünscht, mehrere vertrauenswürdige Verzeichnisse vom Protokoll zu entkoppeln, ähnlich wie bei DNS-Root-Servern oder CAs.

  • Wenn man es individuell machen will, kann man auch did:web:fqdn verwenden. Das wird im Artikel ebenfalls erklärt.

• Jeder Server, der at://-Links speichert, muss am Ende wohl über DNS/HTTPS die kanonische Permalink-Darstellung finden. Wenn DNSSEC nicht korrekt funktioniert, wirkt diese Struktur insgesamt etwas anfällig. Ich habe noch nicht tief darüber nachgedacht, aber meine spontane Sorge wäre, dass ein Angreifer etwa über DNS Poisoning in meinem Namen Beiträge veröffentlichen könnte, weil der Public Key in der über DNS geholten DID steckt.

  • DNS Poisoning ist ein nachvollziehbarer Einwand, aber praktisch nicht immer relevant. Es ist üblich, an der Authority-Stelle in at:// direkt die DID einzusetzen. Wenn man also statt eines Handles die DID abfragt, hängt man am Ende von HTTPS und der Web-PKI ab. Selbst wenn man mit einem Handle beginnt, läuft es über Web-PKI und TXT-Records. Empfohlen wird, dass Server Handles auflösen. Wenn man es selbst machen muss, sollte man einen vertrauenswürdigen DoH-Anbieter verwenden, also DNS over HTTPS. Das ist nicht perfekt, verkleinert die Angriffsfläche aber deutlich. DNSSEC ist natürlich eine Lösung für dieses Problem, aber ich hatte im Betrieb realer Netzwerke schon mehrfach Ärger wegen DNSSEC. Zum Beispiel verwenden US-Senatoren die Domain senate.gov zur Identitätsbestätigung, und vor Kurzem war deren DNSSEC-Konfiguration kaputt, sodass auf Bluesky bei Dutzenden Senatoren „invalid handle“ angezeigt wurde. Wegen solcher frustrierenden Erfahrungen dränge ich derzeit nicht stark auf eine DNSSEC-Pflicht. Wenn ein anderes großes Protokoll erfolgreich DNSSEC erzwungen hätte, könnte man das neu bewerten.
  • Damit ein Angreifer in deinem Namen posten kann, braucht er zwingend deinen privaten Schlüssel. DNS-Records sagen nur, wo das DID-Dokument geholt wird, und dieses DID-Dokument muss dann wiederum gegen DNS verifiziert werden. In diesem Prozess steckt Verifikationslogik. DNSSEC reduziert das Risiko manipulierter DNS-Records, aber ohne DNSSEC kann trotzdem nicht irgendeine beliebige Person erfolgreich als du auftreten und Beiträge veröffentlichen. Server würden das zurückweisen.
  • Dieser Teil ist etwas kompliziert, aber in der DNS TXT method steht ausdrücklich „DNSSEC not required“. DNS dient hier ohnehin nur der Umwandlung von Handle -> DID, während die Verifikation als bidirektionaler Prozess DID -> Handle einbezieht.

• Im Artikel fehlen Informationen über die Schlüssel, die für die Änderungsverläufe der DID verwendet werden. Wenn ich zum Beispiel foobar.bsky.social wäre, erinnere ich mich nicht daran, jemals selbst einen Schlüssel hochgeladen oder eine Aufforderung zum Herunterladen gesehen zu haben. Mich würde interessieren, wo dieser Schlüssel genau liegt, wem er gehört und wie beziehungsweise wann er verwendet wird. Und falls die DID in plc.directory liegt: Welcher Mechanismus verhindert, dass der Betreiber dieser Website meine DID willkürlich überschreibt und damit meine Identität kapert?

• Das Konzept von at:// ist interessant, aber ich mache mir auch Sorgen über Probleme, die in einem System auf Basis von Dateneigentum praktisch auftreten können. Zum Beispiel können Nutzer ihre Daten jederzeit beliebig ändern oder löschen. Man könnte zuerst einen harmlosen Beitrag schreiben und ihn später böswillig verändern. Selbst wenn man alte Hashes speichert, damit Änderungen auffallen, kennen neue Dienste diese Historie womöglich nicht. Auch Dinge wie Upvotes scheinen schwer nachverfolgbar. Wenn jeder alles als eigenes Objekt speichert, ist es schwierig herauszufinden, wer was hochgevotet hat. Und man könnte vermutlich unbegrenzt Fake-Accounts anlegen und nur die eigenen Beiträge pushen. Schließlich frage ich mich, ob Moderation bei der riesigen Zahl von Accounts aus unterschiedlichen Plattformen überhaupt machbar ist, insbesondere gegen Spam oder andere böswillige Aktivitäten. Ich bin mir nicht sicher, ob unter der Annahme, dass jedes Konto seine Daten selbst verwaltet, ein Systemdesign für Transparenz, Verantwortlichkeit, Moderation und Spam-Abwehr insgesamt wirklich tragfähig ist.

  • Änderungsverläufe kann man einfach mitveröffentlichen. In den Daten (json) kann man beliebig viele Informationen mitgeben, daher ließe sich die bisherige Beitragsadresse auch fortlaufend als verkettete Liste mit at:// beschreiben. DID erklärt auch gut, wie Identity Moderation funktioniert, also wie man genügend Grundlage bekommt, um zu erkennen, wer jemand ist, und ihn zu blockieren oder zu beurteilen. Der wichtige Punkt ist, dass das hier keine Blockchain ist, sondern ein Ansatz, der um den Datenbesitzer herum aufgebaut ist und sich jederzeit teilen lässt. Solange niemand mutwillig versucht, alles kaputtzumachen, ist das ein ziemlich attraktives Modell. Man weiß klar, „welche Daten dieser Person wo liegen“. Wenn einem solche Transparenz egal ist, muss man es nicht verwenden.
  • Zum Schutz gegen böswillige Änderungen am Originalinhalt gibt es mit strongRef einen hashbasierten echten Permalink. Dan geht im Artikel nicht detailliert darauf ein, aber wenn man strongRef speichert, merkt man sofort, wenn der Inhalt eines bestehenden Beitrags verändert wurde. Dass Bluesky keine Edit-Funktion eingeführt hat, liegt ebenfalls an der Gefahr böswilliger Änderungen. (Siehe dazu: Permalink-Experimente zu Permalinks und Editing, Experimente zur History bei Record Editing). Das Tracking von Upvotes lässt sich grob durch Crawlen des Netzwerks und Sammeln der Daten lösen, etwa mit roaring bitmaps (Beispiel zu roaring bitmaps). Für Moderation gibt es stackable moderation, was viel cooler ist als bestehende Systeme. Es gibt auch Diskussionen darüber, Labeler und Feedgen als DAG aufzubauen, also als System zur Kombination von Regeln über Mengenoperationen. Probleme durch Datenfälschung erkennt man über die jeweiligen CID-Hashes, und auch das Verfolgen von Änderungsverläufen ist technisch möglich.

• Das erinnert mich an viele Krypto-Protokolle, die von Dezentralisierung sprechen, am Ende aber doch an eine Plattform gebunden bleiben.

  • Es ist noch früh, aber tangled.org (ähnlich wie GitHub) und leaflet.pub (ähnlich wie Medium) werden bereits aktiv genutzt. Mit Tools wie slices.network, die die Netzwerkindexierung automatisch übernehmen, sinkt die Hürde für neue Apps weiter, daher werden wohl noch mehr kommen. Im Artikel wird erklärt, wie das funktioniert. Wichtig ist, dass solche Technik für „normale“ Nutzer gar nicht so bedeutsam ist. Die meisten Bluesky-Nutzer interessieren sich praktisch nicht für „Dezentralisierung“ oder stehen ihr sogar eher ablehnend gegenüber. Aber weil die dezentrale Struktur im Produkt nicht direkt sichtbar ist — ähnlich wie beim Surfen im Web — ist diese Art von Adoption trotzdem möglich. Nutzer wollen einfach, dass es „funktioniert“.
  • Das fühlt sich ein wenig an wie die Vergangenheit von Git und GitHub, die mit wachsendem Funktionsumfang nach und nach dezentraler und flexibler geworden sind.

• Es gibt die strukturelle Frage: „Wie findet man über eine at://-URI das JSON?“ Selbst nach dem Lesen der Dokumentation habe ich kein Gefühl dafür, warum man genau dieses JSON braucht. Persönlich liegt mir dieser Ansatz nicht.

  • Entschuldige, dass die Einführung etwas abrupt war. Das at://-Protokoll ermöglicht es Apps, Daten frei untereinander einzubetten und zu exportieren, Benutzeridentitäten zu teilen sowie Inhalte selbst zu hosten oder umzuziehen. Es liefert dauerhafte URIs, die nicht an Handles oder Server gebunden sind. Wie das technisch funktioniert, wird im ganzen Artikel erklärt. Ein praktisches Beispiel: leaflet.pub und bsky.app aggregieren jeweils Daten aus demselben öffentlichen Netzwerk und können deshalb ohne separate API die Daten des jeweils anderen leicht integriert anzeigen (Demo-Post).
  • Zum besseren Verständnis kann man das mit der Frage vergleichen: „Wie findet man über eine https://-URI HTML?“ Das ist zwar stark vereinfacht, eignet sich aber gut, um es jemandem zu erklären, der DNS, HTTP und TLS zum ersten Mal kennenlernt.

• Ich frage mich, ob das Protokoll im Grunde wie ein riesiges öffentliches Kafka-Topic funktioniert. Also zum Beispiel so, dass man beim Bau einer neuen Web-App die Daten gar nicht selbst speichert, sondern alle Nutzer ihre Daten jeweils in ihrem eigenen Bereich speichern, und man dann einfach Listener darauf setzt, während das Protokoll die Verbreitung garantiert und die App nur lauscht und cached. Konzeptionell ist das faszinierend, aber ich frage mich, ob dabei auch Kafka-Konzepte wie Offsets, damit man keine Updates verpasst, oder Partitionierung für Skalierung gelten.

  • Ja, der Firehose erfüllt fast genau diese Rolle. Jeder kann ihn abonnieren oder selbst einen Firehose betreiben. Siehe auch ATProto für Engineers verteilter Systeme. Firehose und Jetstream haben Cursor, sodass man auch bei später Verbindung noch Updates bis zum aktuellen Stand nachholen kann. Je nach Instanz liegt das Zeitfenster dafür zwischen 1 und 72 Stunden. Wenn man die vollständige Historie braucht, kann man das per Backfill erledigen.