Föderiertes Akteursnetzwerk: Was im Code steht und wohin es zeigt

Ein Tischlermeister sucht im Netzwerk nach Eichenholz, Stärke 40 mm, im Umkreis von 50 Kilometern. Das Holz meldet sich. Nicht das Holz selbst, ein digitaler Stellvertreter, der die Bestände kennt. Eine CNC-Fräse in einer offenen Werkstatt wird stundenweise gebucht. Bezahlt wird gemischt, teils in Euro, teils in direkter Gegenseitigkeit. Das fertige Möbelstück hat selbst ein Profil, es kennt seine Bestandteile, seine Herkunft, seinen CO₂-Fußabdruck. Wird es in zwanzig Jahren zerlegt, fließen die Materialien als eigenständige Ressourcen zurück ins Netzwerk.

Das ist nicht der Stand meiner Codebase. Das ist das Bild, auf das ich seit sechs Jahren zuarbeite. Dieser Artikel zeigt die Linie dahin, was heute davon im Code steht und wohin die Architektur zeigt.

Die Linie: sechs Jahre, drei Stationen

Im März 2020 habe ich mit Linked Open Actors angefangen. Offener Standard plus Prototyp-Suite, um Akteursdaten in föderierten Netzwerken darzustellen. RDF als Datenmodell, ActivityPub als Transportschicht. In Kooperation mit der fairkom-Genossenschaft. Die Lehre: Das Konzept trägt, die Umsetzung scheitert daran, dass die existierenden Fediverse-Server die Standards selektiv interpretieren. Ohne eigenen Server kommt man via Standard gar nicht erst ins Netz.

Parallel arbeitete ich von Oktober 2020 bis November 2021 für das Fraunhofer IESE an einer Microservice-Plattform für den öffentlichen Sektor. Dort habe ich unter anderem das asynchrone Taskmanagement auf Basis von ActivityPub aufgesetzt. Ein Jahr Praxis mit RDF, JSON-LD, Turtle, RDF4J und ActivityPub. Die ActivityPub-Umsetzung im Projekt-Kontext war schwerer durchzuhalten als geplant. Nach meinem Weggang wurde diese Komponente archiviert; die übrige Plattform lief weiter.

Daraus folgte die Entscheidung: Wenn die Server-Landschaft nicht passt, baue einen, der C2S und S2S sauber spricht und beliebige RDF-Typen zulässt. Das wurde rdf-pub, von Dezember 2021 bis September 2025. Vier Jahre, viel gelernt, kein tragfähiges Geschäftsmodell für das Projekt selbst. Im März 2025 traf ich beim Cloudfest-Hackathon die Entwickler rund um das WordPress-ActivityPub-Plugin und merkte: Sie schwimmen auf der WordPress-Welle und lösen andere Probleme als ich. Eine gemeinsame Bewegung gab es nicht.

Im Oktober 2025 habe ich neu aufgesetzt. ChangingGraph ist keine Fortsetzung des rdf-pub-Codes, sondern eine Neuentwicklung in zwei zentralen Aspekten: stärker typisiert und mit einer Plugin-Schnittstelle für weitere Typen. Übernommen sind die Learnings, nicht die Codebasis.

Was heute im Code steht (Stand 2026-05-26)

Vorab: Der hier beschriebene Stand ist stabil, die aktive Entwicklung pausiert zugunsten eines Schwesterprojekts.

ChangingGraph ist ein Java/Spring-System mit neun Bounded Contexts in hexagonalem Schnitt. ActivityPub-Federation läuft in beiden Spielarten: Server-to-Server für die Föderation zwischen Instanzen, Client-to-Server für Apps gegen die eigene Instanz. Die Inbox verarbeitet Follow, Accept, Reject, Undo, Like, Create, Announce, Delete, Update und Offer. Die Outbox liefert dieselben Lifecycles auf der Sende-Seite, mit HTTP Signatures in einem dynamischen, Mastodon-kompatiblen Header-Set.

Sieben FEPs sind implementiert, nicht nur als Vokabular-Klassen, sondern mit Tests:

• FEP-34ec für eine Notifications-Collection
• FEP-4ccd für Pending Followers und Following
• FEP-844e und FEP-40bb für Capability Discovery und Description
• FEP-34c1 für Collection Filtering (TREE)
• FEP-7888 für Conversation-Kontexte inklusive eines Mastodon-spezifischen ostatus-Fallbacks
• FEP-db70 für RemoveAll-Activities

Was Federation tatsächlich kompatibel macht, lässt sich nicht aus einer Spec lesen. Die Roundtrip-Tests gegen 66 JSON-LD-Schema-Samples aus realen Fediverse-Implementierungen sind der Kern: Mastodon, GoToSocial, Pleroma, Akkoma, Misskey, Firefish, Sharkey, Lemmy, Pixelfed, PeerTube, NodeBB, Friendica, Ghost, WordPress, Bridgy-Fed. Die Assertion ist roh: Parse darf nicht zum 400 führen. Sie deckt genau die Lücke, an der LOA und rdf-pub jahrelang gescheitert sind.

Auf Persistenz-Ebene liegen Activities und Objects als RDF im RDF4J-Store, mit Titanium JSON-LD 1.1 für die Roundtrips. Actor-Profile sind im Verlauf der Entwicklung zu JPA migriert worden, eine bewusste Entscheidung gegen RDF dort, wo das Profil ein klar typisiertes Entity ist. Domain Events laufen über ein Outbox-Pattern via ActiveMQ Artemis. Ein Plugin-Mechanismus mit dynamischer ActivityHandlerRegistry erlaubt es, neue Aktivitätstypen ohne Eingriff in den Kern zu ergänzen.

Auf der User-Seite gibt es einen WYSIWYG-Composer auf Tiptap-Basis, ein Social-Dashboard mit fünf Tabs (Timeline, Directed, Notifications, Outbox, Profil), WebFinger-Suche, Follow/Unfollow mit Pending-Accept, einen Account-Lifecycle inklusive E-Mail-Verify und manueller Admin-Approval, SPARQL-Zugang via YASGUI für Administratoren und eine Mobile-First-UI auf Thymeleaf, HTMX und Alpine.js.

Der Stack ist nicht das, was man heute reflexhaft auf die Folie schreibt. Kein SPA, kein TypeScript-Build-Monster, kein eigenes Backend-für-Frontend. Thymeleaf rendert HTML, HTMX tauscht Fragmente, Tiptap übernimmt das Composer-WYSIWYG. Das trägt, auch mobil.

Was ich daraus verstanden habe

Föderation lässt sich nicht durch sauberes Spec-Lesen herstellen. Sie funktioniert oder funktioniert nicht in der konkreten Begegnung mit Mastodon, das in der Praxis der Standard ist, und mit den Spielarten, die sich daran orientieren. Sechs Jahre dieser Arbeit haben aus mir keinen Standards-Romantiker gemacht. Was zählt, ist die Test-Methode: gegen reale Dialekte, nicht gegen die Spec.

Der zweite Lerneffekt liegt in der Schichtung. RDF ist die Datenschicht, ActivityPub ist die Transportschicht. Die beiden zu trennen war der entscheidende Schritt. ChangingGraph speichert RDF, redet ActivityPub und hat eine Plugin-Schicht dazwischen, die beides verbindet. In dieser Struktur können weitere Akteurstypen ohne Schnittstellen-Bruch dazukommen.

Wohin das zeigt

Bis hier Code. Ab hier Vision.

Die Architektur sieht ein Netzwerk vor, in dem nicht nur Menschen und Software-Agenten Akteure sind, sondern auch repräsentierte Ressourcen: Maschinen, Materialien, Räume, fertige Konstrukte. Das Unterscheidungskriterium ist Handlungsfähigkeit, nicht Materialität. Autonome Akteure (Menschen, KI-Agenten) handeln selbst. Repräsentierte Ressourcen werden vertreten, jeweils durch einen Custodian, einen Menschen oder eine Organisation, die ihr Profil pflegt und Konditionen definiert. Die Grenze ist fließend. Eine CNC-Fräse, die heute repräsentiert wird, könnte morgen teilautonom mit eigener Steuerungssoftware agieren. Das Protokoll soll das abbilden können, ohne umgebaut zu werden.

Wissen soll in zwei koexistierenden Formen gehalten werden: Markdown für menschliche Lesbarkeit (und, wie sich gezeigt hat, für LLMs, die mit Markdown weit besser umgehen als mit RDF) und RDF für semantische Verknüpfung und maschinelle Auswertung. JSON-LD ist die Brücke. Dass LLMs mit RDF heute kaum arbeiten, ist eine Tatsache, kein Gesetz. Sobald Agenten stärker mit Wissensgraphen umgehen, verschiebt sich die Balance. Bis dahin laufen beide Spuren parallel.

Konstrukte aus Akteuren sollen wieder Akteure sein: Ein Möbelstück mit eigener Identität, eigener Geschichte und Provenienz, die beim späteren Zerlegen erhalten bleibt. Die Granularität entsteht durch Nutzung, nicht durch Vorgabe.

Eine Designentscheidung steht für alle diese Schichten fest: Das Protokoll, die Ontologien und das geteilte Vokabular sollen Commons sein. Wer aus der Wandel-Szene kommt, kennt das Argument. Wer aus dem Konzern-Umfeld kommt, hat eine andere Lesart, in der dieselbe Konsequenz steht: Ein Netzwerk, dessen Grundregeln proprietär sind, reproduziert die Plattform-Abhängigkeit, die es überwinden soll. Spezifische Dienstleistungen, Skills und Daten bleiben in Hand der Akteure und können entgeltlich angeboten werden. Die Infrastruktur dazwischen bleibt offen.

Wo das gerade steht

Die aktive Entwicklung an ChangingGraph ruht derzeit. Mein Fokus liegt auf einem MCP-Server für semantisches Gedächtnis auf RDF-Basis: ein Schwesterprojekt aus derselben Werkzeugkiste (RDF4J, MCP, Java/Spring), das eine deutlich engere Marktfrage angeht. ChangingGraph bleibt die strategische Linie. Die Federation-Basis ist tragfähig, einige Features liegen unfertig (Like/Boost-Trigger im UI, Bild-Upload im Composer, Delivery-Status-Tracking). Das Repository ist nicht öffentlich.

Wer in einer ähnlichen Richtung baut, wer Spring-AI, MCP-Server oder semantische Schichten in produktive Java-Systeme bringt, kann sich melden. Kennenlernen, austauschen, gemeinsam weiterdenken.

Föderiertes Akteursnetzwerk ist groß. Die einzelnen Schritte sind klein und konkret. Ich nehme einen nach dem anderen.

---

Fred Hauschel ist Software-Architekt und IT-Freelancer in München. Java seit 1999, RDF und Linked Data als strategischer Kern seit dem WirVsVirus-Hackathon 2020. Mehr unter hauschel.de.