| |
“Monolithisches Protokoll”
Matrix will alle für einen modernen Chat erforderlichen Funktionen in einem Protokoll vereinen. Es ist monolithisch. Technisch verzichtet Matrix auf Modularität (also auf das ‘X’ in XMPP). Damit soll eine Fragmentierung vermieden werden. Das ist umstritten („illusorisch“). Im Gegenteil - es wird so viel schwieriger, die Fragmentierung in den Griff zu bekommen:
Das Problem ist, dass heute ‘nötige Funktionen’ nicht denen der Zukunft entsprechen müssen; die Entwicklung geht weiter. Künftige Anwendungsfälle brauchen andere Funktionen und keiner weiß, wie in 5 Jahren der Bereich Sofortnachrichten aussieht.Dem Protokoll fehlen die Mechanismen, um es entsprechend anpassen zu können. Also wird es irgendwann aktualisiert und in der Folge wird es mit alten Servern Schwierigkeiten geben oder überhaupt nicht mehr funktionieren.
Serversoftware ist im Beta-Stadium / noch nicht fertig
Von der Matrix-Seite am 30.07.2018 (ins Deutsche übersetzt):
“Synapse befindet sich derzeit in rasanter Entwicklung, ist aber ab der Version 0.5 unserer Meinung nach ausreichend stabil, um als Internet-Dienst für die reale Nutzung betrieben zuwerden!”
-> Die am fortgeschrittenste Serversoftware ist im Beta-Stadium
Zu wenig funktionierende Brücken (von/zu anderen Systemen)
Seitens Matrix wird auf Verbindungen („Brücken“) verwiesen, um mit anderen Systemen kommunizieren zu können. Diese sind aber oft unfertig oder praktisch nicht nutzbar. Hierin werden keine/zu wenig Entwicklerkapazitäten investiert. Die Brücken sind zur Zeit (Oktober 2018) eher störend und unübersichtlich in der Benutzeroberfläche.
Ressourcen
Was geht mit Matrix, was nicht mit XMPP geht? Genauer: Welche Matrix-Funktionalität wäre mit XMPP tatsächlich nicht möglich, wenn auch hier Geld für die Entwicklung zur Verfügung gestellt würde?
Flexibilität des Protokolls
Für moderne IM-Anforderungen ist das Matrix-Protokoll gut geeignet und einfach zu benutzen (es wäre ja auch schlimm, wenn nicht) - für andere Dinge jedoch wie das Internet der Dinge (IoT) und ggf. künftige IM-Anforderungen nicht wirklich. Also braucht es dafür separate Lösungen, was schade ist.
Schlechte Skalierbarkeit
Die Skalierbarkeit des Protokolls wird in Frage gestellt (das ist bei XMPP schon schwierig - bei Matrix noch viel mehr).
Matrix kann zumindest theoretisch skaliert werden: https://github.com/matrix-org/synapse/blob/master/docs/workers.rst (extern)
Keine echte Unabhängigkeit
Es ist unschön, dass bei Matrix das Protokoll, der relevante Server und der relevante Client aus einer Hand kommt. Wenn die eine Hand (wie 2017) Probleme hat, wird das zum Problem für das gesamte Matrix-Universum.
Strukturelle Schwäche
Alles ist wird als “Raum” betrachtet/behandelt, also können problemlos (versehentlich) mehrere Räume mit demselben Kontakt geöffnet werden. Wenn es Probleme bei der Ende-zu-Ende-Veschlüsselung gibt, muß in irgendwelchen “Raum-Optionen” für den 1:1-Chat nachjustiert werden.
Technische Gedanken zu XMPP-Schnittstellen
Bei Matrix ist da nur IRC als öffentliche Schnittstelle öffentlich erreichbar. XMPP gateways bei Matrix sind nicht zu gebrauchen. Wenn man sich das mal genauer ansieht, dann sieht man, dass allein IRC Gateway gelistet sind. Es gibt auch einen IRCd für Matrix. Der ist aber auch noch tiefste Beta. Laut HP. Aktuell hat man bei Matrix eigentlich nur Matterbridge als stabile Gateway Lösung, oder eben man geht über den IRC. Da ginge z.b. auch eins der großen Netze. oder eben man installiert sich selbst einen IRC. Wenn man sich an eine Bridge per App Service machen möchte sollte man sich einen eigenen IRc Server aufsetzen. Das kommt daher, das der APP Service sehr viele Verbindungen aufmacht. Das lässt normalerweise kein IRC Server zu. Daher wird es auch schwer, einen neuen APP-Service an ein bestehendes Netz zu knoten. Und nein, ein bouncer bzw ein NGinx als Reverve Proxy gehen nicht.
Anmerkung: Wie bei Matrix gibt es auch bei XMPP Gateways: Biboumi, Bittlebi etc. Diese Gateways sind so aber nicht öffentlich erreichbar.
https://www.kuketz-blog.de/messenger-matrix-das-xmpp-fuer-hobby-admins (extern)