|
„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:
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 …
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.
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 |
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.
Beide Systeme können serverseitig für große Installationen skaliert werden:
Der Server “ejabberd” ist für seine Skalierbarkeit bekannt und kann über mehrere Instanzen geclustert werden. (Wikipedia (extern))
Bekanntestes Beispiel/Inselsystem: WhatsApp
Bekanntestes Beispiel/Inselsystem: Tchap (Französische Regierung)
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:
… und zum theoretisch Möglichen:
Sonstige Praxiswerte:
Anmerkung: Quellen mit weiteren aktuellen Zahlen und gerne auch Korrekturen sind willkommen >> Kontakt <<
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):
Weitere Gegenüberstellungen:
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“ |
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!
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.
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?
… 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.
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.
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. |