Longform für das Bluesky-Fediversum

In den letzten Tagen bin ich bei verschiedensten Webdiensten über ihre Ankündigung gestolpert, das Schema Standard.site zu unterstützen, damit auch Longform-Content im Bluesky-Fediversum (also ATmosphere) zu teilen.

Schauen wir uns das einmal an.

Wer schon einmal versucht hat, einen längeren Text im Fediverse zu verbreiten, kennt das Problem: ActivityPub ist für kurze Statusmeldungen optimiert. Mastodon erlaubt inzwischen bis zu 500 Zeichen, manche Instanzen mehr – aber ein ausgewachsener Artikel, ein Newsletter-Essay, ein Blogpost mit Struktur und Tiefe? Das war bislang bestenfalls ein Link ins offene Web, kein echter Teil des Netzwerks.

Im AT Protocol, dem dezentralen Fundament hinter Bluesky, sieht die Ausgangslage technisch besser aus – aber die Frage, wie Longform-Inhalte einheitlich beschrieben, gefunden und zwischen Plattformen ausgetauscht werden sollen, war lange offen. Genau hier setzt Standard.site an.

Was ist Standard.site?

Standard.site ist kein Produkt, kein Unternehmen, kein VC-gefördertes Startup. Es ist ein Koordinationsprojekt von Entwicklern, die auf dem AT Protocol aufbauen – und die unabhängig voneinander festgestellt hatten, dass sie alle dasselbe Problem lösen und dabei ähnliche, aber inkompatible Schemas entwarfen.

Das Ergebnis der Zusammenarbeit: eine Handvoll gemeinsamer Lexicons – so heißen Datenschemata im AT Protocol – für Longform-Publishing. Vier Prinzipien leiten das Projekt:

Unified Discovery – Ein Schema für Indexer und Werkzeuge, statt jede Plattform einzeln unterstützen zu müssen.

Content Portability – Nutzer können zwischen Hosts wechseln, ohne Inhalte, Abonnenten oder Metadaten zu verlieren.

Community Ownership – Gepflegt von den Entwicklern, die damit bauen. Keine einzelne Plattform kontrolliert den Standard.

Minimal Governance – Koordination durch Adoption, nicht durch Komitees.

Die Lexicons selbst sind bewusst schlank gehalten. Sie beschreiben Metadaten: Was ist eine Publikation? Was enthält ein Dokument? Wo lebt es? Das Inhaltsformat selbst – Markdown, HTML, was auch immer – bleibt jeder Plattform überlassen.

Die Kernbausteine

Das Standard.site-Schema besteht aktuell aus vier wesentlichen Lexicons:

site.standard.publication – Beschreibt eine Sammlung von Dokumenten: URL, Name, Beschreibung, Icon, Theme. Das ist das „Impressum" einer Publikation im Netzwerk.

site.standard.document – Metadaten eines einzelnen Textes: Pfad, Zugehörigkeit zu einer Publikation, optional der vollständige Inhalt.

site.standard.graph.subscription – Abonnements: Wer folgt welcher Publikation? Das ermöglicht personalisierte Feeds über Plattformgrenzen hinweg.

site.standard.graph.recommend – Empfehlungen für einzelne Dokumente, als Signal für Aggregatoren.

Das Besondere: Wer einen Blogpost mit einem site.standard.document-Record verknüpft, macht seinen Text zu einem Objekt im AT Protocol. Nicht nur zu einem Link, der auf eine externe Seite zeigt – sondern zu einem Datensatz, den jede kompatible App direkt lesen, indizieren und anzeigen kann.

Die Verification: Domain und Protokoll zusammenführen

Damit Standard.site-Records und die tatsächliche Webpräsenz zusammengehören, gibt es zwei Verifikationsmechanismen:

Für Publikationen wird unter /.well-known/site.standard.publication eine AT-URI hinterlegt – ähnlich wie bei der Bluesky-Handle-Verifikation über eigene Domains. Für Dokumente reicht ein -Tag im der Seite, der auf den entsprechenden AT-URI-Record verweist. Das schließt den Kreis zwischen offenem Web und dezentralem Protokoll.

Bluesky macht den Schritt

Am 28. Mai 2026 hat Bluesky mit dem Update auf Version 1.122 die Integration von Standard.site in die offizielle App freigegeben. Konkret bedeutet das: Wenn jemand auf Bluesky einen Link zu einem Text teilt, der mit einem Standard.site-Record verknüpft ist, erscheint dieser nicht mehr als generische Linkvorschau – sondern als dynamische Link Card, die direkt aus dem AT-Protocol-Datensatz gespeist wird.

Damit können Bluesky-Nutzer Artikel, Blogposts und Newsletter aus dem gesamten AT-Protocol-Ökosystem entdecken – von Plattformen wie Leaflet, pckt und Offprint. Bluesky bringt dabei die Verteilung: über 44,5 Millionen registrierte Accounts. Die unabhängigen Plattformen bringen die Inhalte und das Ownership-Modell.

Das ist strukturell interessant: Bluesky setzt hier nicht auf eine eigene Longform-Funktion, die Nutzende auf die Plattform bindet – sondern auf den offenen Standard als gemeinsame Infrastruktur. Ein Ansatz, der deutlich von X/Twitter abweicht, wo Articles exklusiv für zahlende Nutzer innerhalb der geschlossenen Plattform verfügbar sind.

Das WordPress-Plugin: Bestehende Blogs ins Netz holen

Noch kurz vor der Bluesky-Integration hatte WordPress das ATmosphere-Plugin veröffentlicht – und das ist mehr als ein Crossposting-Tool.

Der Unterschied ist konzeptionell bedeutsam: Andere WordPress-Bluesky-Plugins verhalten sich wie Broadcasts. Ein Artikel wird als Kopie auf Bluesky gespiegelt, aber er bleibt ein externer Link. Das ATmosphere-Plugin hingegen veröffentlicht site.standard.*-Records im AT Protocol. Damit wird der WordPress-Blog selbst zu einem Teilnehmer des Netzwerks, nicht nur zu einem Absender.

Praktisch heißt das: Jede kompatible App kann WordPress-Artikel direkt aus dem AT-Protocol-Account lesen – so wie sie einen Bluesky-Post liest. Kommentare aus Bluesky erscheinen als Kommentare auf der WordPress-Seite, und umgekehrt landen freigegebene WordPress-Kommentare als Replies unter dem Original-Bluesky-Post.

Das Plugin wurde unter anderem von Matthias Pfefferle entwickelt, der seit Jahren WordPress mit dem offenen Social Web verbindet – er hat auch das ActivityPub-Plugin für WordPress gebaut. Die Verbindung zum Fediverse rund um Mastodon bleibt also parallel bestehen; AT Protocol und ActivityPub schließen sich nicht aus.

Das wachsende Ökosystem

Was mich an Standard.site am meisten überzeugt: Es ist nicht exklusiv. Die Implementierungen-Seite zeigt ein bereits ernsthaftes Ökosystem:

Discovery & Indexierung:

Read on pckt – Aggregator für Blogposts aus der ganzen ATmosphere

Docs.surf – Aggregator für Publikationen und Dokumente

Standard Search – Suchmaschine für Standard.site-Inhalte

potatonet – „Find your next read in the network"

Migration & Publishing:

Sequoia – Veröffentlichung von Evergreen-Content in der ATmosphere

Wireservice – WordPress-Publishing auf ATProto

ATmosphere Plugin (WordPress.org)

Entwickler-Werkzeuge:

Standard.site Validator – Prüft, ob ein Post gültige Standard.site-Records hat

Das sind keine Konzepte. Das sind laufende Dienste, die heute nutzbar sind.

Was das für unabhängiges Publishing bedeutet

Ich beobachte das AT Protocol schon eine Weile mit vorsichtigem Interesse. Was mich bremst, ist immer wieder dieselbe Frage: Wer liest das eigentlich? Eine Plattform, die technisch überlegen ist, aber kaum Reichweite hat, bleibt für die meisten Blogger ein akademisches Experiment.

Standard.site und die Bluesky-Integration ändern diese Kalkulation. Wenn mein Blog – oder ein auf AT Protocol nativer Dienst – durch Standard.site-Records Teil des Netzwerks wird, dann ist Reichweite nicht mehr an eine bestimmte App gebunden. Bluesky ist heute der größte Client, aber nicht der einzige. Und wenn jemand einen neuen Client baut, der Standard.site-Records liest, sind alle Inhalte bereits dort.

Das ist das Versprechen des dezentralen Webs, das ActivityPub für soziale Inhalte eingelöst hat – und das Standard.site jetzt für Longform-Texte einlösen will. Kein Vendor Lock-in. Kein Algorithmus, der entscheidet, ob der Artikel ausgeliefert wird. Kein Plattformrisiko.

Ob es klappt, hängt wie immer von der Adoption ab. Die ersten Zeichen sind ermutigend.

Weiterführende Links:

Standard.site – Startseite und Lexicon-Definitionen

Standard.site Dokumentation

Implementierungen im Überblick

Bluesky-Announcement (v1.122)

ATmosphere WordPress-Plugin

ATmosphere 1.0.0 – Liftoff (Hintergrund-Blogpost)