ActivityPub für eine persönliche Website — Was die Federation standardisiert und was bei der Implementierung bleibt

Eine persönliche Website kommuniziert normalerweise in eine Richtung: Der Autor veröffentlicht eine Seite, und Leser besuchen sie. RSS, WebSub und gewöhnliche Hyperlinks machen diese Beziehung nützlicher, aber sie machen die Website noch nicht zu einem Teilnehmer an einem gemeinsamen sozialen Graphen. ActivityPub beginnt mit einer anderen Frage: Was wäre nötig, damit ein Server versteht, dass ein anderer Server etwas veröffentlicht, abonniert, geliked oder aktualisiert hat?

Die Antwort lautet nicht: „Verwende eine universelle Social-Media-Anwendung.“ ActivityPub ist ein Protokoll mit einem dazugehörigen Datenmodell. Es definiert wichtige Nachrichten und Endpunkte, überlässt aber viele sichtbare und betriebliche Entscheidungen der jeweiligen Implementierung. Diese Unterscheidung ist für jeden wichtig, der Federation für eine persönliche Website erwägt. Man kann die Architektur verstehen, ohne anzunehmen, dass jede Website zu einem vollständigen sozialen Netzwerk werden muss.

Activity Streams ist das Vokabular

ActivityPub basiert auf Activity Streams 2.0. Activity Streams stellt eine JSON-basierte Möglichkeit bereit, Objekte und Aktivitäten zu beschreiben. Ein Objekt kann eine Notiz, ein Artikel, ein Bild, eine Person, eine Collection oder ein anderer im Vokabular definierter Typ sein. Eine Aktivität beschreibt eine Handlung wie Create, Follow, Like, Update oder Undo.

Das lässt sich leichter als Satz denn als Datenbanktabelle vorstellen: Ein Actor erstellt ein Objekt, oder ein Actor folgt einem anderen Actor. Die JSON-Darstellung enthält Felder wie actor, object, type und Adressierungs-Eigenschaften. Das Activity Vocabulary definiert gemeinsame Typen und Eigenschaften, während die Core-Spezifikation die JSON-Serialisierung und das Collection-Modell beschreibt.

Das Vokabular ist erweiterbar. Das ist nützlich, weil soziale Anwendungen nicht alle dieselben Objekte oder Aktionen haben. Es schafft aber auch eine Grenze: Eine Erweiterung, die eine Implementierung versteht, kann von einer anderen ignoriert werden. Eine Implementierung kann daher die Form eines Objekts akzeptieren, ohne für jede Erweiterung dasselbe Verhalten anzubieten. Die Interoperabilität wird verbessert, wenn vorhandene gemeinsame Typen verwendet werden, statt für ein bereits bestehendes Konzept einen neuen Namen zu erfinden.

ActivityPub hat zwei zusammengehörige APIs

Die ActivityPub Recommendation beschreibt zwei Protokollebenen:

• Client to server: Ein Client handelt im Namen eines Actors, etwa indem er eine Aktivität an dessen Outbox sendet.
• Server to server: Server liefern Aktivitäten an Actors auf anderen Servern aus. Das ist der Federation-Teil.

Ein Server kann eines dieser Profile implementieren, ohne zwangsläufig beide zu implementieren. Das ist eine wichtige Korrektur der Vorstellung, ActivityPub sei ein einziges monolithisches Feature. Eine persönliche Website könnte zunächst einen maschinenlesbaren Actor und eine Outbox veröffentlichen, während ein größerer Dienst zusätzlich Clients, Authentifizierung, Moderation und Remote Delivery anbietet.

Actors, Inbox und Outbox

In ActivityPub können eine Person, Organisation, Anwendung oder ein Dienst als Actor dargestellt werden. Der Actor wird durch eine URI identifiziert und stellt eine inbox sowie eine outbox bereit. Die Inbox ist der Ort, an dem an den Actor adressierte Aktivitäten empfangen werden. Die Outbox enthält vom Actor erzeugte Aktivitäten, abhängig von den Zugriffsregeln des Servers.

Es kann außerdem Collections wie followers und following geben. Das sind Protokollobjekte und nicht unbedingt Seiten, die ein Mensch sehen muss. Eine Benutzeroberfläche kann sie als Listen darstellen, verbergen, paginieren oder ein völlig anderes Design verwenden. ActivityPub verlangt, dass die entsprechenden Daten und Endpunkte die erwartete Bedeutung haben.

Für einen einfachen öffentlichen Beitrag sieht der Ablauf vereinfacht so aus:

1. Ein Client übermittelt ein neues Objekt oder eine neue Aktivität an die Outbox des Actors.
2. Der Server erstellt oder speichert das Objekt und bestimmt anhand von Adressierungsfeldern wie to und cc die Empfänger.
3. Der Ausgangsserver findet den Empfänger-Actor und dessen entfernte Inbox.
4. Der Ausgangsserver sendet die Aktivität an diese Inbox.
5. Der empfangende Server validiert und verarbeitet die Aktivität nach seinen eigenen Regeln.

Das ist ein Delivery-Modell und keine Garantie dafür, dass der entfernte Server den Inhalt in einer bestimmten Timeline anzeigt. Die empfangende Implementierung entscheidet weiterhin, wie sie die empfangenen Daten speichert, moderiert, sortiert, verbirgt oder darstellt.

Discovery ist ein eigenes Problem

Ein Server kann nichts an einen Actor ausliefern, den er nicht finden kann. ActivityPub stellt stabile Identifikatoren und Endpunkte bereit, aber die Account-Discovery verwendet häufig WebFinger. RFC 7033 definiert ein Protokoll, um Informationen über eine durch eine URI identifizierte Entität zu entdecken. Ein Client sendet eine HTTPS-Anfrage an /.well-known/webfinger mit einem Query-Target und erhält einen JSON Resource Descriptor.

Praktisch kann WebFinger dabei helfen, eine für Menschen lesbare Kennung auf eine Profil- oder Actor-URL abzubilden. Die Grenzen sollten klar bleiben: WebFinger ist ein Discovery-Protokoll und kein Ersatz für ActivityPub-Aktivitätszustellung. WebFinger hat außerdem eigene Datenschutzanforderungen. Über Discovery veröffentlichte Informationen sind leichter auffindbar. Ein Server sollte daher personenbezogene Daten nicht allein deshalb veröffentlichen, weil sie in eine Antwort passen.

Nach der Discovery ruft ein ActivityPub-Client oder -Server einen Actor oder ein Objekt mittels HTTP Content Negotiation ab. Die Recommendation beschreibt Activity-Streams-Darstellungen wie application/activity+json und den Activity-Streams-JSON-LD-Medientyp. Eine HTML-Seite für Browser und eine maschinenlesbare Activity-Streams-Darstellung können auf dieselbe Ressource verweisen, sind aber nicht dasselbe Dokument.

Was ActivityPub nicht standardisiert

Protokolle sind oft besonders nützlich, wenn man erkennt, was sie bewusst offenlassen. ActivityPub schreibt keinen einzigen Timeline-Algorithmus vor. Es legt nicht fest, ob ein Server Beiträge chronologisch, anhand von Empfehlungen, in Listen oder überhaupt in einer Timeline anzeigen muss.

ActivityPub gibt auch kein einheitliches Account-Modell für alle Implementierungen vor. Ein Actor kann eine Person, einen Bot, eine Organisation oder einen Dienst darstellen. Die Beziehung zwischen menschlichen Nutzern und Actors bleibt der Implementierung überlassen. Eine Person kann mehrere Actors kontrollieren, und ein Actor kann automatisiert sein.

Moderation ist nicht gelöst, nur weil eine Inbox existiert. Der empfangende Server braucht weiterhin Richtlinien und Kontrollen gegen Spam, unerwünschte Follows, Identitätsmissbrauch, schädliche Inhalte, Remote-Blockierungen und Einsprüche. Die Security Considerations der ActivityPub-Spezifikation behandeln Validierung, Spoofing, rekursive Objekte, Spam, Federation Denial of Service und Content Sanitization. Diese Hinweise sind aber kein vollständiges Moderationsprodukt.

Auch die Authentifizierung erfordert Sorgfalt. Das Core-Protokoll beschreibt Autorisierung und verweist auf Mechanismen wie Signaturen, aber ein Deployment muss weiterhin ein passendes Profil auswählen und implementieren. Das offizielle W3C-Repository für ActivityPub führt WebFinger- und HTTP-Signature-Profile als zusätzliche Dokumente auf. Ein Server sollte ein syntaktisch gültiges JSON-Dokument nicht als Beweis behandeln, dass es tatsächlich vom behaupteten Actor gesendet wurde.

Warum das für eine persönliche Website wichtig ist

Für eine persönliche Website ist ActivityPub nicht automatisch das nächste Feature nach RSS. Es bringt eine neue Angriffs- und Betriebsfläche mit: stabile Identifikatoren, öffentliche Darstellungen, Remote-Anfragen, Retry- und Deduplikationsverhalten, Zugriffskontrolle, Moderation, Speicherung und Security Review.

Ein vorsichtiger Entwurf kann die Entscheidungen in Stufen aufteilen. Zuerst sollte festgelegt werden, was öffentlich sein soll und welche URLs stabil bleiben. Danach kann eine kleine Activity-Streams-Darstellung für einen Artikel oder Autor definiert werden. Anschließend kommen Discovery und Read-only-Federation in Betracht, bevor Remote Writes akzeptiert werden. Erst wenn Threat Model und Betriebskosten verstanden sind, sollte eine Website Follows, Replies, Likes oder beliebige Remote-Aktivitäten erwägen.

Diese Reihenfolge ist keine Vorgabe der Spezifikation. Sie ist eine Engineering-Abwägung. Das Protokoll macht Federation möglich, aber nicht einfach zu betreiben. Eine kleine Website profitiert möglicherweise stärker von klaren Canonical URLs, RSS, WebSub und einer zugänglichen HTML-Seite als davon, jede Aktivität eines anderen Servers anzunehmen.

Fazit

ActivityPub lässt sich am besten als eine Reihe von Vereinbarungen zwischen Servern verstehen. Activity Streams liefert das Vokabular; ActivityPub definiert Client-Server- und Server-Server-Interaktionen; WebFinger kann bei der Discovery helfen. Actors, Inbox, Outbox, Collections, Adressierung und HTTP-Darstellungen liefern die Bausteine für Federation.

Federation ist jedoch nicht dasselbe wie ein fertiges soziales Erlebnis. Das Protokoll wählt weder Timeline noch Moderationsrichtlinie, Storage Engine, Account-Design oder Sicherheitsmodell für das Deployment. Das ist zugleich seine Stärke und sein Preis. Eine persönliche Website kann ActivityPub als Möglichkeit sehen, über eine einzelne Plattform hinaus zu veröffentlichen, und trotzdem zuerst eine weniger modische Frage stellen: Für welche Teile dieser Beziehung sollte die Website tatsächlich verantwortlich sein?

References

1. ActivityPub, W3C Recommendation, Christine Lemmer-Webber et al., 23 January 2018.
2. Activity Streams 2.0, W3C Recommendation, James M. Snell and Evan Prodromou, 23 May 2017.
3. Activity Vocabulary, W3C Recommendation, James M. Snell and Evan Prodromou, 23 May 2017.
4. RFC 7033: WebFinger, Peter Saint-Andre et al., IETF, September 2013.
5. W3C ActivityPub repository, official project documentation.