Federation im Web3: Matrix, ActivityPub und die Zukunft dezentraler Kommunikation

Es gibt eine Technologie, die seit über fünf Jahrzehnten zuverlässig funktioniert, die Milliarden von Menschen täglich nutzen und die trotzdem kaum jemand als revolutionär bezeichnen würde: E-Mail. Dabei ist E-Mail das vielleicht erfolgreichste föderierte System, das die Menschheit je gebaut hat. Kein einzelnes Unternehmen kontrolliert es. Kein zentraler Server muss laufen, damit es funktioniert. Jeder kann einen eigenen Mail-Server betreiben und trotzdem mit allen anderen kommunizieren. Das Protokoll — SMTP, erstmals 1982 in RFC 821 spezifiziert — ist ein offener Standard, der von niemandem genehmigt werden muss.

Und doch hat die Tech-Industrie in den letzten zwanzig Jahren fast alles daran gesetzt, dieses Modell zu zerstören. Slack, Discord, Microsoft Teams, WhatsApp — jede dieser Plattformen ist eine geschlossene Insel. Sie können nicht miteinander sprechen. Wenn Sie eine Discord-Nachricht an jemanden auf Slack senden möchten, ist das schlicht unmöglich. Wir haben das offene, föderierte Modell der E-Mail gegen komfortablere, aber geschlossene Silos eingetauscht. Und für die meisten Menschen war das ein akzeptabler Handel.

Für DAOs ist es das nicht.

Warum Federation für DAOs existenziell ist

Eine Decentralized Autonomous Organization, die ihre gesamte Kommunikation über Discord abwickelt, hat ein fundamentales Architekturproblem. Die Organisation ist dezentral, aber ihr Nervensystem ist es nicht. Discord kann den Server sperren, die API-Bedingungen ändern oder schlicht ausfallen. Im Januar 2023 führte ein Discord-Ausfall dazu, dass Dutzende von DAOs für Stunden handlungsunfähig waren — keine Governance-Diskussionen, keine Koordination, keine Abstimmungen. Die Entscheidungsgewalt lag plötzlich nicht mehr bei den Token-Inhabern, sondern bei den Systemadministratoren eines Unternehmens in San Francisco.

Das ist kein Randfall. Es ist ein Designfehler. Wenn eine Organisation sich als dezentral versteht, muss auch ihre Kommunikationsinfrastruktur dezentral sein. Nicht aus ideologischen Gründen, sondern aus rein praktischen: Ein Single Point of Failure in der Kommunikation ist ein Single Point of Failure in der Governance. Und eine DAO ohne funktionierende Governance ist keine DAO — sie ist nur eine Gruppe von Leuten mit Token.

E-Mail als Blaupause — und ihre Grenzen

Wenn Federation so wichtig ist, warum nehmen wir nicht einfach E-Mail als Modell? Die Antwort liegt in dem, was E-Mail nicht kann. SMTP wurde für asynchrone, punkt-zu-punkt Kommunikation entworfen. Es gibt keine nativen Gruppenräume, keine Echtzeitkommunikation, keine strukturierten Threads, kein Rechtemanagement. Mailing-Listen sind ein Workaround, kein Feature. E-Mail ist das Äquivalent eines Briefkastens in einer Welt, die Konferenzräume braucht.

Außerdem hat E-Mail ein Identitätsproblem. Ihre E-Mail-Adresse ist an Ihren Provider gebunden. Wenn Sie von Gmail zu Proton Mail wechseln, ändern Sie Ihre Identität. Sie können Ihre Adresse nicht mitnehmen. In einer DAO, in der Reputation und Identität oft über Jahre aufgebaut werden, ist das inakzeptabel.

Also brauchen wir etwas, das die Stärken der E-Mail-Federation — offene Standards, dezentrale Kontrolle, Interoperabilität — mit den Anforderungen moderner Kommunikation verbindet: Echtzeitnachrichten, verschlüsselte Gruppenräume, strukturierte Berechtigungen, portable Identitäten. Und genau hier kommen Matrix und ActivityPub ins Spiel.

Matrix: Das Betriebssystem für föderierte Echtzeitkommunikation

Matrix ist ein offener Standard für dezentrale, echtzeitfähige Kommunikation. Das Protokoll wurde 2014 gestartet und verfolgt einen ambitionierten Ansatz: Jede Unterhaltung ist ein replizierter Datenraum, der über mehrere Server verteilt wird. Wenn Sie auf Ihrem Homeserver einen Raum erstellen und jemand von einem anderen Homeserver beitritt, synchronisieren die beiden Server den gesamten Zustand des Raums. Es gibt keinen primären Server. Jeder beteiligte Server hat eine vollständige Kopie.

Diese Architektur hat weitreichende Konsequenzen. Erstens: Ausfallsicherheit. Wenn ein Server offline geht, können die anderen Server im Raum weiterhin kommunizieren. Der ausgefallene Server synchronisiert sich nach, sobald er wieder verfügbar ist. Zweitens: Souveränität. Jede Organisation kann ihren eigenen Homeserver betreiben und behält die volle Kontrolle über ihre Daten. Drittens: Ende-zu-Ende-Verschlüsselung. Matrix unterstützt E2EE nativ über das Megolm-Protokoll, was bedeutet, dass nicht einmal die Serverbetreiber Nachrichten lesen können.

Für DAOs ist besonders relevant, dass Matrix ein feingranulares Berechtigungssystem hat. Power Levels bestimmen, wer Nachrichten senden, Mitglieder einladen oder Raumeinstellungen ändern darf. Das entspricht im Wesentlichen dem, was DAOs für ihre Governance brauchen: abgestufte Rechte, die an Rollen und nicht an Personen gebunden sind. Theoretisch ließe sich ein Matrix-Raum so konfigurieren, dass Power Levels direkt an On-Chain-Governance gekoppelt werden — wer Token hält, erhält automatisch die entsprechenden Berechtigungen.

Aber Matrix hat auch Schwächen. Die Synchronisation großer Räume über viele Server ist ressourcenintensiv. Synapse, die Referenzimplementierung des Homeservers, ist dafür bekannt, erhebliche Mengen an Speicher und CPU zu verbrauchen. Die neuere Implementierung Dendrite verspricht Besserung, ist aber noch nicht auf dem gleichen Reifegrad. Und Federation bedeutet immer auch Komplexität: Wer ist verantwortlich, wenn ein Spam-Server dem Netzwerk beitritt? Wie werden Konflikte in der Raumzustandsresolution gelöst, wenn Server unterschiedliche Versionen der Wahrheit haben?

ActivityPub: Das soziale Gewebe des dezentralen Webs

Während Matrix für Echtzeitkommunikation optimiert ist, verfolgt ActivityPub einen anderen Ansatz. Das Protokoll, 2018 als W3C-Standard verabschiedet, wurde für soziale Interaktionen entworfen: Beiträge, Kommentare, Likes, Shares. Wenn Sie Mastodon, Lemmy oder PeerTube kennen, kennen Sie ActivityPub. Es ist das Protokoll, das das sogenannte Fediverse antreibt.

Die Architektur unterscheidet sich fundamental von Matrix. Wo Matrix auf replizierte Räume setzt, basiert ActivityPub auf dem Actor-Modell. Jeder Nutzer (oder jede Organisation) ist ein Actor mit einer Inbox und einer Outbox. Aktivitäten — ein Post, ein Follow, ein Like — werden als JSON-LD-Objekte zwischen Actors ausgetauscht. Es gibt keine geteilten Räume, keine Zustandssynchronisation. Stattdessen ist es ein Nachrichtenfluss: Ich sende etwas an Ihre Inbox, Sie verarbeiten es, wie Sie möchten.

Das macht ActivityPub leichtgewichtiger als Matrix, aber auch weniger geeignet für strukturierte Echtzeitkommunikation. Dafür glänzt es bei dem, wofür es entworfen wurde: öffentliche Diskurse, Bekanntmachungen, Community-Building über Servergrenzen hinweg. Eine DAO könnte ihre Governance-Vorschläge als ActivityPub-Posts veröffentlichen, die von Mitgliedern auf verschiedenen Instanzen kommentiert und diskutiert werden — ohne dass alle auf derselben Plattform sein müssen.

Das Identitätsmodell von ActivityPub hat allerdings eine Schwäche, die für den Web3-Kontext besonders relevant ist: Identitäten sind an Instanzen gebunden. Wenn Sie @user@mastodon.social sind und Ihre Instanz schließt, verlieren Sie Ihre Identität. Das ist das gleiche Problem wie bei E-Mail — und für DAOs, die auf souveräne Identitäten angewiesen sind, ein ernsthaftes Hindernis.

Die Identitätsfrage: Wo Web3 den Unterschied machen kann

Und hier wird es philosophisch interessant. Sowohl Matrix als auch ActivityPub haben das Problem der servergebundenen Identität. In beiden Protokollen ist Ihre Identität letztlich eine Adresse auf einem Server, den jemand anderes betreibt. Das ist ein fundamentaler Widerspruch zum Web3-Prinzip der Self-Sovereign Identity.

Die Lösung liegt — zumindest konzeptionell — auf der Hand: Kryptografische Identitäten, die unabhängig von jedem Server existieren. Ein DID (Decentralized Identifier), der auf einer Blockchain verankert ist, könnte als Brücke dienen. Sie authentifizieren sich bei einem Matrix-Homeserver oder einer ActivityPub-Instanz mit Ihrem DID. Wenn Sie den Server wechseln, nehmen Sie Ihre Identität mit. Ihre Reputation, Ihre Verbindungen, Ihre Berechtigungen — alles bleibt erhalten.

Das ist keine reine Theorie. Es gibt bereits Experimente in diese Richtung. Matrix arbeitet an einem Konzept namens „Portable Identities“, das genau dieses Problem adressieren soll. Im ActivityPub-Ökosystem gibt es Vorschläge, DIDs als Actor-Identifier zu verwenden. Aber wir sind noch weit von einer produktionsreifen Lösung entfernt.

Federation als Designprinzip, nicht als Feature

Was mich an der aktuellen Diskussion stört, ist die Tendenz, Federation als optionales Feature zu behandeln — etwas, das man nachträglich hinzufügen kann, wenn die Kernfunktionalität steht. Das ist ein Missverständnis. Federation ist kein Feature. Federation ist eine Architekturentscheidung, die das gesamte System durchdringt. Sie beeinflusst das Datenmodell, das Identitätsmanagement, die Konfliktresolution, die Performance-Architektur, das Berechtigungssystem. Man kann ein zentralisiertes System nicht nachträglich föderieren, genauso wenig wie man ein Gebäude nachträglich erdbebensicher machen kann.

Bei Just Tech Solutions beschäftigen wir uns intensiv mit dieser Frage — nicht zuletzt im Kontext unserer Arbeit an CommonGround, einer Community-Plattform, die Federation als Designprinzip ernst nimmt. Die Herausforderung besteht darin, die Stärken beider Welten zu vereinen: Die strukturierte Echtzeitkommunikation von Matrix, die soziale Vernetzung von ActivityPub, und die souveräne Identität von Web3.

Das ist kein triviales Problem. Aber es ist ein lösbares Problem. Die Protokolle existieren. Die Standards existieren. Was fehlt, ist die Integrationsarbeit — und der Wille, Federation nicht als Kompromiss zu betrachten, sondern als Voraussetzung.

Ein Blick nach vorne

Wenn ich fünf Jahre in die Zukunft schaue, sehe ich zwei mögliche Szenarien. Im ersten Szenario haben wir die Fehler des Web2 wiederholt: Eine Handvoll DAO-Plattformen hat sich durchgesetzt, jede mit ihrem eigenen geschlossenen Ökosystem. DAOs sind dezentral in der Governance, aber zentralisiert in der Kommunikation. Das Versprechen der Dezentralisierung bleibt unerfüllt.

Im zweiten Szenario haben wir die Lektion der E-Mail gelernt — aber diesmal richtig. Federation ist der Standard. DAOs betreiben ihre eigenen Kommunikationsserver, die über offene Protokolle miteinander verbunden sind. Identitäten sind portabel und kryptografisch gesichert. Kein Unternehmen kann einer DAO die Kommunikation abschneiden, weil es keine zentrale Instanz gibt, die das könnte.

Der Unterschied zwischen diesen beiden Szenarien wird nicht durch Technologie entschieden — die Technologie existiert bereits. Er wird durch Designentscheidungen entschieden, die heute getroffen werden. Jedes Tool, das eine DAO heute für ihre Kommunikation wählt, ist eine Stimme für eines dieser beiden Szenarien.

E-Mail hat bewiesen, dass Federation in planetarischem Maßstab funktioniert. Matrix und ActivityPub haben bewiesen, dass moderne, reichhaltige Kommunikation föderiert werden kann. Web3 hat die Werkzeuge für souveräne Identität geschaffen. Die Frage ist nicht, ob dezentrale Kommunikation für DAOs möglich ist. Die Frage ist, ob wir den Mut haben, sie zu bauen.