Vergleich XMPP/Matrix

- Lesezeit: 14 Minuten -

Vorwort

XMPP oder Matrix“ - Was ist besser? Diese Frage ist so nicht zu beantworten, da jedes der beiden freien und anbieterunabhängigen Systeme seine Vor- und Nachteile hat. Die Systeme sind nicht besser oder schlechter, sondern unterschiedlich in der Konzeption und deshalb nicht perfekt für jeden Anwendungsfall. Die manchmal verwendete Formulierung „Matrix vs XMPP“ ist für beide Seiten kontraproduktiv, denn es geht nicht um ein „Gegeneinander“ sondern um das „Miteinander“.

Teilweise wird die Frage, welche App verwendet werden soll so beantwortet:

  • WhatsApp => Conversations (XMPP; Android) u.a.
  • Slack => Element (Matrix)

Das ist jedoch nur eine sehr grobe und subjektive Empfehlung.

Unterschiedliche Prioritäten

Je nachdem, aus welcher Position man schaut, gibt es mal mehr oder mal weniger große Unterschiede. Auch haben Privatpersonen, Firmen, Hoster oder politische Vertreter ganz individuelle Prioritäten und können Punkte ganz unterschiedlich bewerten und gewichten …

Private Nutzer

Aus dem Blickwinkel von privaten Nutzern ist WhatsApp der Maßstab - oder Datenschutz. Es geht nicht um Teamarbeit, die Serverauslastung und -performance ist nicht relevant und wie die Übertragung im Hintergrund funktioniert ist ebenso egal. Hautpsache die App/das Programm (der Client) funktioniert.

Merkmal Chatstandard (XMPP) Matrix
Clients für alle Betriebssysteme ja ja
Einheitliche Benutzeroberfläche bei verschiedenen Betriebssystemen (OS) nein ja
Clients mit reiner Text Benutzeroberfläche (TUI) ja ja (alle im Beta-Status) (extern)
Desktopclient ohne Electron ja ja, FluffyChat (Flutter) *
„Halb-Anonymität“ / Anzeige der Chatadresse in öffentlichen Chaträumen (anderen Teilnehmern gegnüber) ja / wird nicht angezeigt, kann vom Raumadministrator aktiviert werden nein / Adressen sind immer öffentlich; eine Deaktivierung ist nicht möglich

*) Andere Electron-freie Desktop-Clients sind nicht zu empfehlen, da diese sich noch im Entwicklungstatus (Alpha/Beta) befinden oder nicht weiterentwickelt werden.

Nutzerzahlen

Großanwender

Nutzer wie Unternehmen oder Behörden haben ganz andere Bedürfnisse wie Privatanwender. Hier sind Funktionen zur Gruppenarbeit sowie die Integration verschiedener Dienste wichtiger, weshalb „Teammessenger“ gefragt sind. Unterschiede der Protokolle:

Protokoll Chatstandard (XMPP) Matrix
Ausfallsicherheit von Chaträumen über mehrere Server nein ja
Verschlüsselung von Chaträumen aktivierbar und deaktivierbar aktivierbar
Speicherort von Administrationsdaten auf jeweils 1 Server für alle Teilnehmer auf jeweils allen Servern der beteiligten Teilnehmer
Speicherort von Gesprächsverläufen für eine einstellbare Vorhaltezeit und/oder bis zur Abholung durch den Nutzer auf dem Server bei dem der Chatraum eingerichtet ist / nach Abholung jeweils auf dem Server der Nutzer auf jeweils allen Servern der beteiligten Teilnehmer
Datenspeicherung auf Server zur Verteilung von Nachrichten auf mehrere Geräte deaktivierbar ja, kann vom Raumadministrator deaktiviert werden; individuell vom Nutzer auch für jeden Chatraum und Kontakt nein, kann nicht deaktiviert werden

Hoster/Serverbetreiber

Protokoll Chatstandard (XMPP) Matrix
Konzeption Basis ergänzbar um jeweils einzelne Erweiterungen (XEP) monolithische Protokoll (alles in einem)
Sprache XML (extern) Extensible Markup Language JSON (extern) JavaScript Object Notation
Fokus auf Flexibilität und Erweiterbarkeit Ausfallsicherheit von Chats/Chaträumen
Ressourcenverbrauch (CPU, RAM, Plattenspeicher) geringer als Matrix höher als Jabber(XMPP)
Ort der Datenspeicherung
(betrifft Ausfallsicherheit aber auch Datenschutz)
nur auf dem Server, auf dem der Chatraum eingerichtet ist auf jedem Server aller beteiligten Teilnehmer
Brücken zu anderen Systemen (viel per Web-API) ja ja
Nachrichteneingang Direktempfang falls TCP-Verbindung offen ist (in die beide Seiten Daten ohne Aufforderung senden können), ansonsten Info über Nachricht per Push-Nachricht Immer erst Push-Nachricht über neue Nachricht an Client, der die Nachricht dann vom Server abholt (das regelmäßige, aktive Nachfragen („polling“) muß betrieben werden, da das Protokoll HTTP zustandslos („stateless“) ist)
Vorteil „Grünere“ Nutzung der IT (weniger Ressourcenverbrauch) Bei Ausfall/Wartung eines Servers können Teilnehmer von anderen Servern ohne Unterbrechung weiterschreiben.

Anmerkung zu „Push“:
Bei Apps aus dem F-Droid-Store wird auf Google FCM verzichtet. Deshalb gibt es hier kein “push” und man muss die App im Vordergrund halten, was wiederum einen größeren Strombedarf erfordert und dann wieder mit Matrix-Apps für Android vergleichbar ist. Für Gerätesteuerung (internet of things / IOT) besser geeignet.

Anmerkung zu „Pull“:
Durch oftmaliges Fragen nach neuen Nachrichten ist der Strombedarf tendenziell größer - außer man vergrößert den Abfrageintervall entsprechend (z.B. auf mehrere Sekunden), was dann ggfs. jedoch keiner „Sofortnachricht“ mehr entspricht. Für Gerätesteuerung (internet of things / IOT) weniger gut geeignet.

Server/Performance

  • für die Nutzer in der Praxis irrelevant
  • für Ökologen und Theoretiker („Mehr Rechenleistung und mehr Speicherplatz <-> grüne IT“) relevant
  • für Wirtschafter und Entscheider wichtig: Die in der Folge zu erwartenden Kosten je Nutzer/Endgerät
  • für Serverbetreiber (Fremd-/Eigenhosting) sehr wichtig in Bezug auf Hardware zwecks Ressourcenbedarf und Fehlertoleranz

Beide Systeme können serverseitig für große Installationen skaliert werden:

Skalierung XMPP

Der Server “ejabberd” ist für seine Skalierbarkeit bekannt und kann über mehrere Instanzen geclustert werden. (Wikipedia (extern))

Bekanntestes Beispiel/Inselsystem: WhatsApp

Skalierung Matrix

Bekanntestes Beispiel/Inselsystem: Tchap (Französische Regierung)

Ressourcenbedarf

Es wird viel vom Speicherbedarf geredet, aber Zahlen aus der Praxis (die sich von den theoretischen Werten manchmal unterscheiden) sind nur wenige zu finden. Hier ein paar gesammelte Informationen zunächst aus der Praxis:

  • Disroot.org (extern): Matrix 141 GB uso de db 4.6 GB RAM Con 21 usuarixis en linea / XMPP 6 GB uso de db 371 MB RAM con 475 usuarixs en linea
  • blog.windfluechter.net (extern): Matrix-Synapse (PostgreSQL): 5 GB für 1 Nutzer / XMPP (PostgreSQL): 0.4 GB für 200 Nutzer
  • mastodon.social (extern): Matrix-Server bei feneas.org ca. 100 Nutzer = 8 GB RAM
  • matrix.org - verbesserte CPU-Auslastung (extern): A big week for matrix.org performance

… und zum theoretisch Möglichen:

  • process-one.net (extern): 2.000.000 Geräte auf einer XMPP-Instanz
  • erlang-solutions.com (extern): XMPP-Server-Test “… And so it went, until we reached fifteen nodes, at over 1.2 million users and 22 thousand messages per second, no limit was in sight. …”
  • ejabberd (extern): 1.500 Nutzer (XMPP) = 90 MB
  • Zahlen zu Matrix fehlen hier noch -> gerne mitteilen!

Sonstige Praxiswerte:

Anmerkung: Quellen mit weiteren aktuellen Zahlen und gerne auch Korrekturen sind willkommen >> Kontakt <<

JSON und XML

XML steht für “Extensible Markup Language”, während JSON für “JavaScript Object Notation” steht.

JSON und XML sind beide für Webdienste geeignet -> es gibt kein wirkliches besser oder schlechter für den Anwendungszweck „Chat“.

Die Hauptunterschiede sind (zur Information):

  • JSON ist eine Erweiterung von JavaScript, während XML eine Erweiterung von SGML ist.
  • JSON ist datenorientiert, XML ist dokumentenorientiert
  • JSON enthält keine Start- und End-Tags, während XML Start- und End-Tags hat
  • JSON unterstützt Datentypen und Arrays, während XML keine expliziten Datentypen und keine Arrays unterstützt
  • JSON unterstützt keine Namespaces, XML unterstützt Namespaces
  • JSON ist für Konfigurationsdateien weniger geeignet, da es keine direkte Kommentarsyntax gibt

Weitere Gegenüberstellungen:

Protokoll/Politik

Ein Unterschied ist die Bestätigung des Protokolls durch eine internationale und unabhängige Standardisierungsgremium. In Fall des Internets und der Protokolle dafür ist hier die IETF in Verbindung mit der XMPP Standard Foundation (XSF) zuständig. So soll eine eine gewisse Qualität eines Standards erreicht und Unabhängigkeit gesichert werden. Beide Protokolle sind quelloffen. Heißt sie sind komplett einsehbar und überprüfbar:

Protokoll Chatstandard (XMPP) Matrix
IETF-Standard ja nein
Öffentliches Protokoll ja ja

Wie wird die Unabhängigkeit des Protokolls nun in der Praxis sichergestellt bzw. wie sind die Regelungen zu den handelnden Personen/Organen, die über die Spezifikationen (das „Protokoll“) bestimmen und entscheiden können?

Protokoll Chatstandard (XMPP) Matrix
Benennung von Führungspersonal (Formaler Prozess) Der Vorstand („board“) und die technische Arbeitsgruppe („council“) werden von den Mitgliedern frei gewählt Die vorhandenen Personen in der Führung entscheiden über Neubesetzungen und sollen dabei auf Neutralität achten.
Kontrolle und Vertrauen: Die Kontrolle liegt bei den Mitgliedern, welche Vorstand und technischen Rat jährlich neu wählen. Es sollte „Neutralität zwischen Matrix.org Foundation und New Vector Ltd“ herrschen. „Die Community sollte ihnen trauen.“
Auskunftspflicht: Die Akteure müssen ihre Arbeitgeber/Interessen benennen ?
Sonstiges: Der personelle Anteil einer Körperschaft/Organisation im Führungsgrremium ist geregelt und begrenzt Personalunion von 2 Führungskräften in Spezifizierungsgremium (Matrix.org) und Dienstleistungsfirma (New Vector Inc.)
Regelungen/Quellen: Bylaws (extern; Internetseite) Official Articles” (extern; PDF) und Rules (extern; PDF)
bei „Legal Details“

Erläuterungen zu den Regeln bei XMPP

Quellen: Allgemeine Beschreibung der XSF (extern) und Regeln („Bylaws“) (extern) der XSF

Für die Mitglieder (Members) gilt, #2.1:

An applicant for membership may not be admitted if, at the time of application or consideration, fifteen percent (15%) of the Members of the Corporation are employed by or represent the same corporation or organization as that corporation or organization which employs the applicant or is represented by the applicant.

Deshalb müssen bei Anträgen zur Mitgliedschaft die relevanten Zugehörigkeiten angegeben werden!

Kontrollverlust an Dritte

Die Regelungen der IETF (IETF-RFCs) und der XSF (XSF-Bylaws) sollen zumindest klarstellen, dass eine „Übernahme“ nur feindlich-konfrontativ möglich ist und daher zumindest die Kosten eines Konflikts zu erwarten sind.

Erläuterungen zu den Regeln bei Matrix

Quellen: Official Articles” (extern; PDF) und Rules (extern; PDF)

Im ersten Dokument, #17.1 der “official articles of the Foundation”:

The Guardians shall appoint any individual who is eligible as a Guardian to fill a vacancy or (subject to the maximum number permitted by Article 16.1) as an additional Guardian, subject to any requirements set out in the Rules from time to time, and provided at least 75% of the current Guardians approve the appointment.

Für die Anforderungen wird auf das zweite Dokument #3.1.4 verwiesen:

The Founder Guardians shall be joined by additional Guardians (with the Founder Guardians forming a minority of the Board) to ensure there is continuity, but also neutrality, between the Foundation and New Vector Ltd.

Und weiter bei #3.1.5 und #3.1.6:

Guardians are typically independent of the commercial Matrix ecosystem and may not even be members of today’s Matrix community, but are deeply aligned with the mission of the project and Guiding Principles. The Guardians are self-appointing […]. However, any Guardian appointed must be respected and trusted by the wider Matrix community to uphold the Guiding Principles and keep the other Guardians honest.

Noch klären / Fragen:
- Warum wird zwischen Gründungswächtern („founder guardians“) und normalen Wächtern („guardians“) unterschieden?

Kontrollverlust an Dritte

  • Was wäre, wenn ein internationaler Konzern wie Goolge so bei Matrix einsteigt wie das früher auch schon mal bei XMPP der Fall war? Oder ein Großinvestor der das Protokoll für seine Zwecke ändern/erweitern will?
  • Gibt es eine Regelung für einen solchen Fall oder wird dadurch eine Übernahme durch Dritte möglich/erleichtert? Muß man sich einfach darauf verlassen, daß die Foundation die Neutralität sicherstellt?

Andere Vergleiche

… wobei dort leider oft die Frage „Was ist besser?“ gestellt wird. Eigentlich halte ich jedoch die Frage „Was ist anders?“ für sinnvoller, denn unterschiedliche Anforderungen können zu unterschiedlichen (anderen) Lösungen führen.

Unterschied lt. Matrix

Matrix selbst findet den Unterschied relativ subjektiv und formuliert:

… The whole area of XMPP vs Matrix is quite subjective. Rather than fighting over which open interoperable communication standard works the best, we should just collaborate and bridge everything together. The more federation and interoperability the better.

Quelle: https://matrix.org/faq/#what-is-the-difference-between-matrix-and-xmpp? (extern; englisch)

… allerdings werden hier verschiedene Begriffe wie Brücken, Föderation und Interoperabilität in einem Satz verwendet. Da oft unterschiedliches Verständnis dazu vorhanden ist, sind deshalb ein paar Gedanken dazu angebracht.

Entscheidungskriterien

Jabber(XMPP) und Matrix unterscheiden sich grundsätzlich in ihrer Systemarchitektur. Auch bei den jeweils vorhandenen Clients gibt es Unterschiede: So herrscht auf der einen Seite eine große Vielfalt mit unterschiedlichen Funktionen - auf der anderen Seite gibt es einen Referenzclient, der für alle Betriebssysteme die selben Funktionen anbietet.

Was ist für eine Entscheidung nun wichtiger: Systemmerkmale oder Clientfunktionalität ?

Es gibt keine allgemeingültige Antwort:
Langfristig kann es besser sein, das für sich besser passende System zu wählen - unabhängig von der Betrachtung der Clients. Kurzfristig ist vielleicht eine allumfassende Clientlösung wichtig. Bei Körperschaften/Organisationen hilft hierbei vielleicht auch die Überlegung, in welchen Bereichen (Clientverbesserung/-Anpassung oder System-/Protokollverbesserung) investiert werden soll/kann.

Ideal wäre eine Kooperation von Matrix und dem Chatstandard (XMPP) durch funktionierende Brücken). So wäre ein standardisierter Austausch von Nachrichten mit Anderen möglich - und trotzdem können Unternehmen/Behörden intern die Vorteile von ausfallsicheren Chaträumen genießen.