Warum wir Matrix aufgegeben haben (2024)

• Aufgrund der strukturellen Sicherheitsgrenzen des Matrix-Protokolls und operativer Probleme ist die Hack-Liberty-Community zu SimpleX gewechselt
• Offenlegung von Metadaten, Missbrauch von Administratorrechten und Schwachstellen in der Verschlüsselung beeinträchtigen Privatsphäre und Sicherheit der Nutzer erheblich
• Auch die von der Matrix.org-Organisation gesammelten personenbezogenen Daten sowie Cloudflare-Eingriffe als Man-in-the-Middle und das Ende der Tor-Browser-Unterstützung werden als Gründe für den Vertrauensverlust genannt
• SimpleX übermittelt Nachrichten ohne Benutzerkennungen und stärkt die Sicherheit mit 2-Hop-Onion-Routing und postquantenresistentem Schlüsselaustausch
• Dieser Wechsel wird als praktische Alternative präsentiert, um Sicherheit und Privatsphäre für dezentrale Communities zu gewährleisten

---

Grenzen föderierter Protokolle

• Föderierte Netzwerke bieten durch die Interaktion mehrerer Server Zensurresistenz, bringen aber grundlegende Sicherheitsprobleme im Design mit sich
  • Nach über zwei Jahren Betrieb öffentlicher föderierter Dienste wie Matrix und Lemmy wurden strukturelle Mängel bestätigt, die allen föderierten Protokollen gemeinsam sind

Probleme des Matrix-Protokolls

Offenlegung von Metadaten

• Bei Matrix sind Absender von Nachrichten, Nickname, Profilbild, Reaktionen, Lesebestätigungen und Zeitstempel nicht verschlüsselt
  • Aufgrund von Nachrichtenvalidierung, Performance-Anforderungen und Unzulänglichkeiten im Protokolldesign besteht ein Teil dieser Metadaten-Offenlegung absichtlich oder als Designfehler
  • Als Beispiel werden Links zu realen Leckagefällen angeführt

Admin-in-the-Middle-Angriffe

• Ein böswilliger Server-Administrator kann allein durch Abfragen der Synapse-Datenbank Nutzerinformationen, Reaktionen und Raum-Metadaten sammeln
  • Auch aktive Angriffe wie Identitätsvortäuschung, Ändern von Raumthemen, beliebiges Einladen oder Ausschließen und Manipulation von Berechtigungen sind möglich
  • Durch das Hinzufügen eines neuen Geräts ist zudem Zugriff auf E2EE-Nachrichten möglich; Warnungen für Nutzer können dabei ignoriert werden

Strukturelle Schwächen des Protokolls

• Matrix arbeitet als teilreplizierte Graph-Datenbank, wobei 22 wesentliche Schwachstellen genannt werden
  • Darunter nicht löschbare Events, Spam-Anfälligkeit, inkonsistente Historie, mögliche Nachrichtenfälschung, selektive Verschlüsselung, Signaturinkonsistenzen, Split-Brain-Raumerstellung und Risiken illegaler Medienreplikation
  • Zustandsinkonsistenzen zwischen Servern können zum Verlust administrativer Rechte oder dazu führen, dass Räume nicht geschlossen werden können

Schwachstellen der Megolm-Verschlüsselung

• Im Megolm-Protokoll von Matrix wurden zahlreiche praktisch relevante kryptographische Schwachstellen gemeldet
  • Dazu gehören verschiedene Angriffsszenarien wie Zusammenbruch der Vertraulichkeit, Verifizierungsangriffe, vertrauenswürdige Imitation und IND-CCA-Angriffe
  • Die Angriffe setzen die Kooperation des Servers voraus und lassen sich in Kernbibliotheken des Element-Clients (matrix-js-sdk usw.) reproduzieren

Übermäßiger Ressourcenverbrauch

• Der Synapse-Server benötigt viel CPU, Arbeitsspeicher, Speicherplatz und Bandbreite
  • Je nach Nutzerzahl sind 4 bis 12 Instanzen erforderlich, wodurch die Betriebskosten übermäßig hoch werden

Probleme der Matrix.org-Organisation

Datensammlung

• matrix.org und vector.im sammeln regelmäßig Nutzerdaten wie E-Mail, Telefonnummer, IP-Adresse, Geräteinformationen, Nutzungsmuster und Raum-IDs
  • In den Standardeinstellungen werden personenbezogene Daten offengelegt; hochgeladene Dateien, Bilder und Profilinformationen sind öffentlich zugänglich
  • Selbst bei Nutzung eines eigenen Servers werden sensible Daten an zentrale Server übertragen

Verbreitung von Material sexueller Ausbeutung von Kindern

• Aufgrund der langsamen Reaktion von Matrix.org konnten Zehntausende Pädokriminelle illegale Inhalte verbreiten
  • Durch nicht schließbare Räume, ungeprüfte Medien-Uploads und automatische Replikation verbreiten sich illegale Materialien im gesamten Föderationsnetz
  • Es ist sehr wahrscheinlich, dass einzelne Homeserver dadurch illegale Inhalte hosten

Cloudflare-Eingriffe als Man-in-the-Middle

• Es wurde bestätigt, dass der TLS-Verkehr von matrix.org und vector.im bei Cloudflare terminiert wird, wodurch die Möglichkeit von Man-in-the-Middle-Angriffen besteht

Ende der Tor-Browser-Unterstützung

• Der Element-Webclient unterstützt den Tor Browser nicht mehr
  • Wegen der alten Firefox-Basis von Tor, fehlender Testbarkeit und mangelnder Finanzierung wurde dies mit keiner geplanten weiteren Unterstützung eingestellt

Probleme im Zusammenhang mit Lemmy

• Aufgrund derselben föderierten Struktur wie bei Matrix treten dieselben Probleme mit Datenreplikation, Zensur und Verantwortung für illegale Inhalte auf
  • Durch De-Federation als Form zensierender Dezentralisierung, Groupthink und Manipulation von Up- und Downvotes wird die freie Diskussion eingeschränkt

Wechsel zu SimpleX

Kommunikationsstruktur ohne Kennungen

• SimpleX verwendet keinerlei Benutzerkennungen wie Telefonnummern, E-Mail-Adressen oder öffentliche Schlüssel
  • Für jede Unterhaltung werden unabhängige unidirektionale Nachrichtenwarteschlangen-Adressen genutzt, um die Verbindung zum Gegenüber zu anonymisieren
  • Künftig soll durch automatische Queue-Rotation auch Serverwechsel und Schutz vor Nachverfolgung unterstützt werden

Schutz vor Spam und Missbrauch

• Kontakt ist nur möglich, wenn Einladungslinks oder temporäre Adressen direkt geteilt werden; unerwünschte Zugriffe werden dadurch blockiert
  • Durch Ändern oder Löschen von Adressen lässt sich Spam vollständig unterbinden

Vollständige Datensouveränität

• Alle Nutzerdaten werden ausschließlich auf dem Client-Gerät gespeichert, Server übernehmen nur die Rolle temporärer Relays
  • Auch im Server-zu-Server-Verkehr können Sender und Empfänger nicht identifiziert werden; die Nachrichtenübermittlung ist nicht zurückverfolgbar

Von Nutzern betriebenes Netzwerk

• Jeder kann eigene SimpleX-Server betreiben; mit SDK und offenem Protokoll lassen sich Bots und Services entwickeln

Vergleich mit Matrix

Punkt	SimpleX	Matrix
Verschlüsselung	Doppelte Verschlüsselung + postquantenresistenter Schlüsselaustausch	Megolm (Schwachstellen vorhanden)
Nachrichten-Routing	2-Hop-Onion-Routing	Föderierte Struktur, Offenlegung von Metadaten
Dezentralisierung	Keine zentralen Komponenten	Zentrale Bootstrap-Knoten vorhanden
Medienverarbeitung	Lokale Verschlüsselung und manuelle Queue-Rotation	Ungeprüfte Uploads, automatische Replikation
Tor-Unterstützung	Unterstützt und mit Onion-Routing	Unterstützung eingestellt
Cloudflare	Nicht verwendet	TLS-Terminierung über Cloudflare

Technische Merkmale von SimpleX

• Ende-zu-Ende-Verschlüsselung auf Double-Ratchet-Basis, postquantenresistenter Schlüsselaustausch, 2-Hop-Onion-Routing
• Unterstützung für Tor und SOCKS-Proxys, sichere Kanäle mit TLS 1.2/1.3, Signaturstruktur zum Schutz vor Replay-Angriffen
• Vollständig dezentrales Netzwerk, Flux-Integration zur stärkeren Metadatenschutz

Nutzererlebnis und Zusatzfunktionen

• E2EE-Sprach- und Videoanrufe, verschlüsselte Benachrichtigungen, lokale Dateiverschlüsselung, Nachrichtenbearbeitung und Reaktionen, akkuoptimierte Gruppenchats
• Anonymer Modus, Konsolenclient, Bot-SDK, Linode-One-Click-Serverbereitstellung und weitere Erweiterungsfunktionen

Zukünftige Roadmap

• Geplant sind höhere Stabilität, Unterstützung großer Communities, Privacy- und Security-Slider, ephemere Unterhaltungen, Standortfreigabe und Automatisierungsregeln

---

Fazit: Hack Liberty wechselt wegen der strukturellen Sicherheitsmängel von Matrix und mangelndem Betriebsvertrauen zu einem vollständig datenschutzorientierten Netzwerk auf Basis von SimpleX. SimpleX wird mit kommunikation ohne Kennungen, starker Verschlüsselung und dezentraler Struktur als sichere Community-Plattform der nächsten Generation vorgestellt.

[GN⁺]

Hacker-News-Kommentare

• Ich wollte wirklich, dass Matrix Erfolg hat, aber inzwischen habe ich es komplett aufgegeben.
  Das State-Resolution-System ist viel zu komplex und ressourcenhungrig. Räume gehen immer noch kaputt. Selbst das bloße Berechnen der Mitgliederliste eines Raums ist so ineffizient, dass die DB-Größe mehrere GB erreichen kann.
  Außerdem fehlen selbst nach Jahren immer noch grundlegende Funktionen wie benutzerdefinierte Emojis, Benutzerstatus und Einladungslinks.
  Zugehörige Issues: #339, #573, #426
  SimpleX finde ich in letzter Zeit interessant, weil es ein ähnliches Ziel wie Signal verfolgt, aber einen anderen Ansatz wählt. Allerdings wirkt es noch nicht so, als hätte es sich in der Breite durchgesetzt.

  • Ich wollte auch, dass Matrix Erfolg hat, bin aber nur halbwegs ausgestiegen. Früher habe ich meinen Synapse-Homeserver selbst betrieben, aber der Ressourcenverbrauch war viel zu hoch. Deshalb bin ich wieder zu XMPP zurückgekehrt. Wenn man einfach nur Chat anbieten will, ist XMPP deutlich effizienter. Bei SimpleX will ich noch warten, bis es etwas reifer ist.
  • Das Problem der State Resolution hat sich seit Project Hydra stark verbessert. Das Problem mit der DB-Größe liegt an der Speichereffizienz von Synapse. Ich habe in diesem Video gezeigt, wie man es lösen kann, aber Priorität hatte erst einmal die Behebung der State-Resets.
    Für Funktionen wie benutzerdefinierte Emojis oder Benutzerstatus gibt es bereits MSC-Vorschläge, und die Implementierung läuft. Seit 2023 lag der Fokus wegen Finanzierungsproblemen und aus Gründen des Überlebens vor allem auf Regierungsprojekten.
  • Ich würde gern fragen, ob du XMPP ausprobiert hast.
  • Ich habe SimpleX etwa ein Jahr lang als Standard-Server genutzt, und es hat gut funktioniert. Ich habe versucht, eine Signal-Gruppe zu SimpleX umzuziehen, bin damit aber gescheitert, und am Ende wurde es nicht weiter genutzt.
  • Ich nutze seit Jahren denselben Matrix-Raum.

• Für mich und mein Umfeld war die Matrix-Erfahrung sehr positiv. Über Beeper und Element haben wir Dutzende nichttechnische Nutzer onboardet, und alle kommen gut damit zurecht. Auch Gerätewechsel sind kein Problem, und verglichen mit Discord ist die UX ziemlich konkurrenzfähig.
  Deshalb verstehe ich die Beschwerden auf HN nicht. Ich vermute, dass da vielleicht alte Server oder inkompatible Clients genutzt werden.

  • Matrix ist inzwischen fast fertig, deshalb reagieren die Leute vielleicht empfindlicher auf die verbleibenden Mängel. In den letzten Jahren lag der Fokus bei Deployments im öffentlichen Sektor, daher hatten Funktionen für die Konkurrenz zu Discord geringere Priorität.
  • Self-Hosting war okay, aber für Leute, die von Discord kamen, waren Einladungslinks und der Registrierungsprozess viel zu kompliziert. Vor allem die Änderung am Sprachchat-System hat bestehende Installationen kaputtgemacht, und die Dokumentation war unzureichend.
  • Ich betreibe meinen persönlichen Server ebenfalls mit einem Ansible-Skript (matrix-docker-ansible-deploy); das läuft stabil und zuverlässig. Vermutlich ist es ein Unterschied in der Erfahrung mit dem öffentlichen Server (matrix.org).
  • Ich nutze es auch problemlos. Für kleine Chats mit Freunden funktioniert es perfekt.
  • Mich würde interessieren, wie die Erfahrungen in Bezug auf Sicherheit sind.

• SimpleX behauptet, es gebe „keine Benutzerkennungen“, aber tatsächlich wird die IP-Adresse direkt offengelegt. Das gesamte öffentliche Netzwerk wird von nur zwei Unternehmen gehostet: Akamai und Runonflux.
  Tor sollte standardmäßig mitgeliefert werden, und die Option zur IP-Verschleierung sollte klar erklärt werden. Derzeit bedeutet es nur, dass „keine zusätzlichen Kennungen erzeugt werden“; die IP selbst wird nicht geschützt.

  • Ich bin der Netzwerkarchitekt von SimpleX. IP-Adressen sind Internet-Kennungen, keine SimpleX-Kennungen. Das Ziel von SimpleX ist es, Korrelationen zwischen IPs zu verhindern und die Offenlegung gegenüber Servern zu vermeiden, die der Nutzer nicht selbst gewählt hat.
    Warum Tor nicht eingebettet wird, ist in den FAQ erklärt.
  • Ich mache mir Sorgen, weil es Anzeichen dafür gibt, dass SimpleX eine eigene Kryptowährung aufbauen will.

• Zu Matrix selbst habe ich keine Meinung, aber ich empfehle dringend, das Nebuchadnezzar-Papier zu lesen. Der Kern sicherer Gruppen-Messaging-Systeme ist nicht Verschlüsselung, sondern die Verwaltung der Gruppenmitgliedschaft.
  Link zum Paper

  • Es wäre interessant, so etwas mit einem System wie FOKS (https://foks.pub) zu kombinieren.
  • Ich habe zum ersten Mal die Matrix-Protokolldokumente gelesen, und mein Eindruck war, dass sie von jemandem geschrieben wurden, der verteilte Systeme nicht gut versteht. Es wirkt wie eine Mischung aus IRC und XMPP ohne Konzepte wie Lamport-Clock oder virtual synchrony.
    An der Stelle, an der man mit mehreren Versuchen der DAG-Sortierung so etwas wie Konsens erreichen will, hatte ich das Gefühl, dass das Projekt grundsätzlich in die falsche Richtung läuft. Da würde ich lieber direkt einen Gruppenchat mit NNTP + GnuPG bauen.

• Ich habe das Jahresend-Update für Matrix veröffentlicht: Matrix Holiday Special 2025
  Ich wünsche allen einen schönen Jahresausklang :)

• Ich nutze Matrix seit 6 Jahren. Während des großen Zustroms 2020 war es schwierig, aber inzwischen ist es stabil.
  Ich ärgere mich immer noch über Bugs und die Langsamkeit von Element Web, aber es gibt viele leichtgewichtige alternative Clients.
  Die Verschlüsselung von Metadaten ist noch nicht vollständig, aber für meine Alltagsgespräche ist das kein großes Problem.
  Ich bleibe bei Matrix wegen der unersetzlichen Kombination aus föderierter Struktur, E2EE, Multi-Device, freier Software und der Möglichkeit zum Self-Hosting.
  Auch die ruhige Führung des Projektleiters schafft Vertrauen.

  • Sehe ich auch so. Wegen eines Memory-Leaks in Element Web nutze ich einen eigenen Fork (Issue-Link).
    Mit dem Wechsel auf matrix-rust-sdk dürfte es große Verbesserungen geben. Ich bin auch auf das Aurora-Projekt gespannt.
  • XMPP kann fast dieselben Funktionen mit viel weniger Ressourcen bereitstellen. Für Videoanrufe braucht man zwar einen TURN-Server, aber es funktioniert gut.

• Moxie (Signal-Gründer) hat 2020 auf dem CCC einen Vortrag gehalten, in dem er auf die Probleme föderierter Systeme hingewiesen hat.
  Video-Link

  • Sein Blogpost von 2016, The Ecosystem Is Moving, ist immer noch relevant. Ich lese ihn jedes Mal wieder, wenn ich die Probleme verteilter Systeme sehe.
  • Zentralisierte Systeme sind bei der Koordinationsfähigkeit immer im Vorteil; wenn verteilte Systeme also keinen klaren Daseinsgrund haben, werden sie am Ende zur Nische.
  • Sammlung verwandter Diskussionen:
    • Why federated protocols don't work (2022)
    • The Ecosystem Is Moving (2019)
    • Reflections: The ecosystem is moving (2016)
  • Am Ende lief sein Argument darauf hinaus: „Wir wollen uns schnell bewegen und den Client frei verändern können.“ Wenn man aber absolute Kontrolle über den Client braucht, verliert E2EE einen Teil seiner Bedeutung.

• Der Aussage „Why Federation Must Die“ stimme ich nicht zu. Föderation ist schwierig, aber unter Regulierungen wie Chatcontrol ist sie innerhalb der EU der einzige Weg, sichere Kommunikation aufrechtzuerhalten.
  Zentralisierte Systeme kann man unter Druck setzen, indem man nur eine Organisation ins Visier nimmt; bei föderierten Systemen ist Kontrolle schwieriger, weil alle ihre eigenen Server betreiben.

  • Der Artikel plädiert nicht für Föderation, sondern für vollständige Dezentralisierung.
  • Ich bin ebenfalls für Föderation. Mastodon zeigt, wie wichtig eine freiere Struktur gegenüber Zentralisierung ist. Auffindbarkeit ist schwieriger, aber dafür ist die Autonomie größer.

• Das Anti-Big-Tech-Lager ist in Wirklichkeit ein Bündnis verschiedener Wertvorstellungen.
  Die eine Seite priorisiert Föderation und Autonomie, die andere Verschlüsselung und Privatsphäre.
  Wenn man anerkennt, dass die Prioritäten unterschiedlich sind, wäre vielleicht eine großzügigere Zusammenarbeit möglich, auch ohne völlige Übereinstimmung.

  • Das sehe ich genauso. Mir sind Self-Hosting und Interoperabilität wichtig, andere priorisieren eher E2EE und minimale Metadaten.
    Ein Projekt wie Matrix kann kaum beide Lager vollständig zufriedenstellen.
    Außerdem ist die Stimme des Sicherheits- und Privatsphäre-Lagers lauter, weshalb der Diskurs oft negativer wirkt, als die Realität es hergibt.

• Dieses Jahr arbeiten wir an Verbesserungen beim Metadatenschutz von Matrix.

  • MSC4362: Verschlüsselung des Raumzustands
  • MSC4256: Entfernung des Senders und MLS-basierte Verschlüsselung
    In der Vergangenheit lag der Fokus auf der Stabilisierung föderierter Verschlüsselung, daher hatte der Metadatenschutz geringere Priorität.
    Außerdem legt schon der Netzwerkverkehr selbst viele Metadaten offen, weshalb vollständige Verbergung schwierig ist.
    Trotzdem sind für 2026 weitere Verbesserungen geplant.
    Zur Einordnung gibt es auch diese Präsentation von 2016: Matrix Jardin Entropique (PDF)
    Manche Behauptungen, etwa dass Daten an einen zentralen Server gesendet würden, stimmen nicht. Die Medienauthentifizierung ist seit Juni 2024 aktiv, und 2025 wurde auch das Trust-and-Safety-Team ausgebaut.
  • Die Leute wollen zwar selbst hosten, aber am Ende wollen sie doch einen bezahlten Hosting-Dienst. Wenn es viele Sicherheitsprobleme gibt, könnte das sogar eher eine Geschäftschance für Hosting-Anbieter sein.
  • Die Haltung „Betreib deinen Server selbst“ dürfte langfristig schwer Unterstützung finden. Zu erwarten, dass normale Nutzer zu halben Systemadministratoren werden, ist unrealistisch.