Matrix

- Lesezeit: 19 Minuten / ganze Rubrik: 24 Minuten -

Anbieterunabhängiger Chat auf Basis des Protokolls “Matrix” ist eine Empfehlung in der Schnellübersicht!

„Matrix“ wird seit 2014 entwickelt und ist wie XMPP ein freies, föderales Messenger-Protokoll. Es ist aktuell nicht als Internetstandard durch die IETF definiert. Es ist nicht bekannt, ob sich Matrix.org um eine öffentliche Standardisierung der Kommunikationsprotokolle bemüht.

Der Fokus liegt auf der Ausfallsicherheit von Chaträumen. Chaträume werden unter allen beteiligten Servern der Teilnehmer synchronisiert (auf jedem beteiligten Server sind alle Nachrichten des Raumes gespeichert). Das bedeutet bei einem eventuellen Ausfall eines Servers, dass alle Teilnehmer von anderen Servern den Chatraum ganz normal weiternutzen können. Bezogen auf die Versionsverwaltung „git“ könnte man sich das ungefähr als „chat over git“ vorstellen. Natürlich ist das nicht tatsächlich „git“ - aber das Prinzip ist ähnlich und deshalb für das Verständnis evtl. hilfreich.

Ein weiterer Vorteil von Matrix ist, dass es quasi für alle Plattformen gut funktionierende Clients gibt.

Konzeptionell ist das Protokoll monolitisch (aus einem Guß) und besteht nicht aus unterschiedlichen oder erweiterbaren Modulen. Bei neuen oder veränderten Anforderungen wird das Protokoll als Einheit geändert/ergänzt. Die Serverimplementation kann dabei auch aus mehreren Teilen bestehen, solange der Server als Ganzes, die Matrix Spezifikation komplett unterstützt.

Für Telefonie (Audio-/Videotelefonie) wird seitens des Protokolls „WebRTC“ verwendet - für Videokonferenzen dagegen „Jitsi“. Jitsi widerum verwendet die XMPP-Erweiterung „Jingle“ zum Signalieren der Videostreams zwischen Clients und Bridge. Darüber hinaus wird „XMPP MUC“ zur Verwaltung der Konferenzräume verwendet.

In der Philosophie von Matrix ist grundsätzlich jeder Chat ein Raum - auch wenn 2er-Chats nicht so gekennzeichnet werden. Für einen Chat mit egal wie vielen Nutzern (auch in eigenen Chats für sich selbst, um sich bspw. selbst Notizen über mehrere Clients zu senden) wird also ein Raum erstellt. Auf Grund dieses Umstand kann also jederzeit ein persönliches Gespräch um weitere Teilnehmer ergänzt werden.

Am 15. Juli 2020 wurde der Matrix-Referenz-Client „Riot“ (der Messenger), New Vector (die Firma) und Modular (Webhosting für Matrix-Server) in „Element“ unbenannt.

Quellen (alle englischsprachig):

Im Gegensatz zu anderen Messengern wie Telegram sind die Strukturen (Informationen zur Firma, den beteiligten Personen sowie zur Finanzierung) öffentlich:

Seltsam ist jedoch folgende Selbsteinschätzung von Matrix.org:
„… abschließendes positives Fazit: matrix.org/foundation ist eine ziemlich solide Stiftung (hah) in Bezug auf die Führungsstruktur - wir schützen das Protokoll so weit wie möglich vor Sabotage durch unser zukünftiges Ich (oder irgendjemand anderen).“
(Maschinell aus dem Englischen übersetzt.)
Quelle: https://twitter.com/matrixdotorg/status/1197297411300958208 (extern; englisch)

Auf der Github-Seite: https://github.com/vector-im (extern) sind viele Quelldateien zu Riot und RiotX verfügbar. Aber auch vieles andere wie z.B. die Internetseiten von element.io und vector.im aber auch Logos von Element, Matrix, Riot und Vector.

Offene Fragen:

  • Es werden Ressourcen ausgegeben, um die eigene Stiftung zu gründen - und dann soll die Arbeit bei irgendeiner Normenorganisation eingereicht werden?
  • Warum nicht direkt bei der für Internetstandards zuständigen Stelle (IETF) einreichen? Ist eine Abbildung von JSON in einem RFC nicht gewünscht?
  • Vielleicht sind Erweiterungen zur Einzeldokumentenspezifikation geplant? Wer würde eventuelle Erweiterungen genehmigen? Welche Rolle spielt hier die eigene Stiftung?

Ende-zu-Ende-Verschlüsselung

Die Matrix-Ende-zu-Ende-Verschlüsselung hat das Betastadium im Mai 2020 verlassen und ist in privaten Chaträumen aktiviert.
Quelle: https://github.com/vector-im/riot-web/issues/6779#issuecomment-624140449

Technisch basiert die Verschlüsselung auf „Olm“ bzw. „Megolm“. Es ist eine Implementierung des Double Ratchet-Verfahrens, das auch Grundlage der bei Jabber bekannten OMEMO-Verschlüsselung ist. 2016 wurde die Olm-Implementierung von der ncc group geprüft. >> Prüfbericht vom 01.11.2016 << (PDF-Datei)
Quelle: nccgroup (extern).

Die Einführung der Verschlüsselung im Echtbetrieb fand jedoch überhastet statt und viele Benutzer wussten nichts vom „Beta“-Stadium (das erst im Mai 2020 abgeschlossen wurde):
„negatives: the python server impl (synapse) was rushed & we are still paying off tech debt; it’s still a bit of a resource hog. E2EE is still not force-enabled until we have full parity with non-E2EE. The SS API is fairly subtle (there are few alt impls). The groups API sucks.“
Maschinell aus dem Englischen übersetzt:
„Die python-server-Implementierung (synapse) wurde überstürzt installiert & wir sind immer noch dabei, unsere technischen Schulden zu begleichen; er ist immer noch ein bisschen ressourcenfressend. E2EE ist immer noch nicht zwingend aktiviert, bis wir volle Parität mit Nicht-E2EE haben. Die Server-Server-API ist ziemlich subtil (es gibt nur wenige Alt-Impls). Die API der Gruppe ist sch….“
Quelle: Twitter-Eintrag vom 21.11.2019 (extern)

Zum Verschlüsselungsprotokoll von Matrix gibt es eine gute (aber leider nur englischsprachige) Ausführung/Beschreibung (extern).

Verschlüsselung deaktivieren?
In manchen Fällen kann es sinnvoll sein, die Verschlüsselung bei Bedarf zu deaktivieren. Beispielsweise wenn über Brücken mit Nutzern anderer Systeme kommuniziert werden soll.

Datenschutz

Aktuell gibt es noch keine deutschen Allgemeinen Geschäftsbedingungen (AGB). In den “privacy notice” ist jedoch zu lesen:

“2.1.2 Right to Erasure - “We therefore share state events sent by your account with all non-essential data removed (‘redacted’), even after we have processed your request to be forgotten. This means that your username will continue to be publicly associated with rooms in which you have participated, even after we have processed your request to be forgotten.”
übersetzt in etwa:
“Daher teilen wir die von Ihrem Konto gesendeten Statusereignisse mit allen nicht wesentlichen Daten, die entfernt wurden (“redigiert”), auch nachdem wir Ihre Anfrage, vergessen zu werden, bearbeitet haben. Das bedeutet, dass Ihr Benutzername weiterhin öffentlich mit Räumen in Verbindung gebracht wird, an denen Sie teilgenommen haben, auch wenn wir Ihre Anfrage, vergessen zu werden, bearbeitet haben.”
Quelle: https://matrix.org/legal/privacy-notice

Das bedeutet, daß die Beziehung von Personen zu Raumen nicht gelöscht werden kann, was im Zusammenhang mit der DSGVO evtl. zu prüfen ist.

Durch die Empfehlung zur Eingabe der Telefonnummer (Identitätsserver) werden diese in einem zentralen Verzeichnis vorgehalten.

Es gibt keinen “malware check”:
In der Vergangenheit wurde usercontent.riot.im als Sandbox zum Entschlüsseln von Dateien verwendet. Der Dateiinhalt wurde nie an irgendeinen Server gesendet, die Domäne diente nur einer statischen HTML-Datei, die in einem Iframe verwendet wurde (siehe: https://github.com/matrix-org/usercontent) (extern). Auch diese Abhängigkeit wurde kürzlich entfernt und durch einen Iframe mit dem Sandbox-Attribut ersetzt: https://github.com/vector-im/riot-web/pull/12292 (extern)
„In the past, usercontent.riot.im was used as a sandbox for decrypting files. The file contents were never sent to any server, the domain only served a static HTML file that was used in an iframe (see: https://github.com/matrix-org/usercontent) (extern). Also, even that dependency was recently removed and replaced with an iframe with the sandbox attribute: https://github.com/vector-im/riot-web/pull/12292 (extern)“
Quelle: Aus weitergeleiteter Information per E-Mail

Mit „The Grid“ gibt es eine Matrix-Abspaltung, die mehr Freiheit und Datenschutz zum Ziel hat. Zwar stimmen einige der dort aufgeführten Punkte, allerdings wurden diese jedoch größtenteils behoben: https://matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4 (extern).
„The Grid’s data collection papers contained some valid points, which were mostly fixed: https://matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4 (extern)“
Quelle: Aus weitergeleiteter Information per E-Mail

Englischsprachige “Hinweise zum Datenschutz und zur Datenerfassung von Matrix.org:

  • Teil 1 (extern): Focusing on the software stack and the privacy impact of its default configuration.
  • Teil 2 (extern): Focusing on GDPR compliance, example of a GDPR Information and Data request, and disclosure of a Personal Data Breach by Matrix.org

Brücken („Matrix-Bridges“)

Matrix bietet verschiedene Brücken („bridges“) an, um mit anderen Systemen (IRC, Slack, Gitter oder auch XMPP) Daten auszutauschen. Es wird also versucht - wie bei unterschiedlichen Sprachen - zwischen diesen zu übersetzten. Ideal für die Nutzer wäre es, wenn diese von diesem Vorgang überhaupt nichts mitbekommen und alle Funktionen wie gewohnt nutzen könnten. Es ist jedoch sehr schwer bzw. aufwändig, zwei unterschiedliche Systeme mit allen jeweiligen Regeln („Protokollen“) komplett kompatibel zu machen. Deshalb kann eine Brücke i.d.R. nur eine begrenzte Schnittmenge an Funktionen bereitstellen wie z.B. den Austausch von einfachen Nachrichten.

Matrix selbst stellt dies auf dem „Web3 Summit“ im Mai 2020 wie folgt dar:
“Mit dem Kommunikationsprotokoll Matrix sollen Nutzer – unabhängig der jeweiligen App – miteinander kommunizieren können.”

Matrix-Brücken Quelle der Bildschirmkopie: t3n.de
Hierauf wird auch im entsprechenden Artikel bei t3n.de (extern) eingegangen.

ABER:
Die Grafik scheint das Ziel aus Sicht von vector.im (Matrix) darzustellen und ist keine neutrale Darstellung der Gesamtzusammenhänge (was auch nicht behauptet wird), denn:

  1. Das Schaubild kann suggerieren, daß zwischen den Systemen und systemübergreifend ohne Probleme und in vollem Funktionsumfang kommuniziert werden kann (was falsch wäre).
  2. Es fehlen Verbindungen(Brücken/Transports) z.B. von IRC oder Jabber(XMPP) auch zu anderen Systemen.
  3. Die Brücke zu Jabber(XMPP) wird auf der offiziellen Internetseite von Matrix nicht aufgeführt.

Und:
Wird die Dienstleistung von matrix.io (extern) als weltweit größtem Matrix-Hoster in Anspruch genommen, stehen aktuell genau drei Brücken zur Auswahl: „Gitter“, „IRC“ und „Slack“
Zitat: „Contact us to find out about additional bridges which may be available soon, or as an add-on for your Element Matrix Services server.“
Quelle: https://element.io/element-matrix-store#bridges (extern)

Bei Matrix.org (extern) werden „bridged traffic delay“, „Freenode“, „Slack“, „Gitter“, „Gimpnet“, „OFTC“ und „Snoonet“ aufgeführt.

XMPP-Bridge

Mit entsprechenden Anpassungen auf den Servern ist es möglich, unverschlüsselte Nachrichten zwischen Matrix- und XMPP-Räumen auszutauschen. Der Dienst auf dem Matrix-Server ist somit wie ein Benutzer zu sehen, der sich im Jabber-Raum als „normaler“ Nutzer anmeldet und wie ein Roboter einfach alle Einträge in den Matrix-Raum weiterleitet bzw. auch in die andere Richtung sendet.

Unklare Positionierung

Auf der einen Seite wurde noch mit Brücken zwischen den Protokollen Matrix und XMPP geworben und mehrmals angekündigt - auf der anderen Seite wird Jabber(XMPP) überhaupt nicht bei den Matrix-Brücken (extern) aufgeführt bzw. mit keinem Wort erwähnt - auch nicht im element-matrix-store (extern). Statt dessen finden sich neben E-Mail, IRC und tox in der Übersicht hauptsächlich geschlossene Systeme.

Dieser vermeintliche Widerspruch in der Geschäftspolitik ist zu hinterfragen und schade, denn gerade das standardisierte XMPP ist komplett quelloffen und frei einsehbar. Allerdings verbirgt sich bei den Matrix-Brücken hinter „libpurple“ die „matrix-bifröst“-Brücke (extern; s.u.) mit dem Hinweis: „Marionettenbrücke für allgemeine Zwecke mit libpurpule und anderen Systemen. Diese Brücke befindet sich zur Zeit in sehr aktiver Entwicklung und ist hauptsächlich für Experimentier- und Evaluierungszwecke gedacht.“
Zitat: „General purpose puppeting bridges using libpurple and other backends. This bridge is in very active development currently and intended mainly for experimentation and evaluation purpose.“
-> Diese ist u.a. auch für das Protokoll „XMPP“!

Bifröst-Bridge

Mit „Bifröst“ gibt es eine Brücke, die auf der FOSDEM 2020 (extern) vorgestellt wurde:
Zitat: „… and demonstrate high quality bridging with XMPP, Slack, Discord, WhatsApp, and more!

Technische Details hierzu finden sich bei: https://github.com/matrix-org/matrix-bifrost/wiki/Address-syntax (extern). Zudem bietet matrix.org anscheinend eine öffentliche Instanz der Brücke an:
Zitat vom 02.05.2020: „matrix.org hosts a public instance of Bifröst for XMPP bridging. You can join any chat from either side of the bridge using the address syntax below. …“

Somit funktioniert:

  • Hinzufügen einzelner XMPP-Nutzer zu 1:1 Unterhaltungen (also unabhängig von Gruppen/öffentlichenChaträumen):

    • über die Internetseite(!?): -> invite -> @xmpp=40:matrix.org
    • über den Client „Element“ -> +chat -> invite ID -> @_xmpp_xmppusername=40xmppserver.TLD:matrix.org
  • Einladungen in einen bereits bestehenden Chatraum

    • Die native Verbindung zum Verbinden von XMPP-Chaträumen für Matrix-Nutzer:
      #_xmpp_CONFERENCE.SERVER.TLD_MUCNAME:matrix.org
      (anstatt des teils “CONFERENCE” natürlich je nach server individuell auch: room/rooms/muc/chat/…
    • Der Befehl lautet: /join #xmpp_:matrix.org
    • Beispiel, wie man in den öffentlichen Chat von “Freie Messenger” kommt: /join #_xmpp_conference.jabber.de_conversations:matrix.org
  • Andersherum kann ein XMPP-Nutzer einen Matrix-Nutzer über matrixuser_matrixserver.TLD@bridge.xmpp.matrix.org erreichen.

  • Tippbeanachrichtigungen werden auf der Matrix-Seite angezeigt (“XY tippt geade”).

Github: https://github.com/matrix-org/matrix-bifrost (extern)

Einschränkungen (Stand 07/2020):

  • Die Kommunikation in dem Raum darf nicht Ende-zu-Ende-verschlüsselt sein.
  • Vereinzelt können Jabber(XMPP)-Chaträume nicht betreten werden, wenn über die Matrix-Brücke anstatt „beitzutreten“ versehentlich „erstellen gewählt wird. Dann erscheint die (falsche) Fehlermeldung „does not exist“.
  • Bei über die Brücke versandten Bildern fehlt die Dateierweiterung, so dass hier ohne manuelles Hinzufügen von z.B. „.JPG„“ oder „.PNG“ nur das Vorschaubild angezeigt wird.

Gedanken zur XMPP-Bridge

Grundsätzlich sind für Verbindungen von Matrix zu XMPP drei Möglichkeiten für Entwicklungen einer Verbindung (bridge/transport) denkbar:

  1. Eine echte, direkte Brücke (wo ein Matrix-Nutzer im XMPP-Raum einen eigenen Namen („alias/nickname“) bekommt und umgekehrt) - so wie das mit „bifröst“ aktuell möglich ist.

  2. Ein Automatismus in Form eines einzeln angelegten Benutzers, der alle Nachrichten einfach weiterleitet - als Roboter (=robot = bot) - ist/war fehleranfällig.

  3. Kommunikation über eine dritte Stelle
    z.B. über IRC. Vorteil ist, daß man den “matrix app service” nutzen kann.
    Ablauf: Der Matrix-Server geht über einen matrix-irc-appservice, der sich mit einem IRC-Kanal verbindet. Das Selbe müsste dann von xmpp aus (z.B. per „biboumi“ in den selben IRC-Kanal.
    Dies hätte jedoch einen entscheidenden Nachteil: Kommunikation über eine Drittes System und somit mehr Komplexität und Fehleranfälligkeit.

Matrix-ID

Aufbau der Benutzerkennung im Echtbetrieb: @benutzername:servername.tld
Für Verbindungen, die über IRC in anderen Systeme gehen: #channel%ircserver@xmpp_component

Berechtigungen

Für Teilnehmer von Gruppenchats gibt es verschiedene Berechtigungsstufen. Diese Einstellung/Änderung kann ein Raum-Administrator derzeit nur vom PC aus machen:

  • 0 - Standard
  • 50 - Moderator
  • 100 - Administrator

Die Heraufstufung von Benutzern zu Moderatoren oder zu Administratoren kann dann jedoch auch Mobil z.B. über ein Smartphone/Tablet gemacht werden.
Achtung: Benutzer die Administrationsrechte bekommen, können nicht mehr zurückgestuft werden. Einmal Admin = Immer Admin.

Server

Bei der Server-Installation werden zunächst selbst signierte TLS-Zertifikate erstellt, die dann jedoch problemlos durch Let’s Encrypt-Zertifikate ersetzt werden können. Dies muss manuell vorgenommen werden. Für die Kommunikation zwischen verschiedenen Servern (Föderation) wird standardmäßig der Port 8448 genutzt.

Neben der Standard-Matrix-Serversoftware „Synapse“ gibt es auch noch andere Lösungen wie z.B. Conduit (extern), mit dem eine eigene Matrix-Insel (ohne Föderation) betrieben werden kann. Die Serversoftware kann sogar auf einem Mini-Computer wie dem Raspberry Pi installiert werden.

Element.io bietet selbst auch einen Dienst zum Hosten von Matrix an: https://ems.element.io (extern)

Eigener Server

  • Tipp 1: Bei einem eigenen Synapse-Server ist auch Hausautomation möglich.
  • Tipp 2: Wenn keine öffentlichen Räume besucht werden sollen:
    In diesem Fall Synapse bezüglich der Föderation beschränken bzw. nur lokal unter 127.0.0.1:8448 lauschen lassen und eine Föderation zusätzlich per Whitelist beschränken. D.h. die Konfigurationsdatei (homeserver.yaml) entsprechend anpassen und bei federation_domain_whitelist: einfach - <EigenerServerName> eintragen.

Chaträume

Clients

Es gibt für so gut wie alle Betriebssysteme funktionierende Klienten (Programme/Apps) (extern, englisch).

  • Element ist der Referenzclient mit der größen Verbreitung; mehrere Chatkonten sind nicht gleichzeitig nutzbar.

  • Zom (extern)
    Mit ZOM für Android und iOS (früher ein XMPP-Client; jetzt Matrix) können mehrere Chatkonten genutzt werden. Es ist möglich, sich hier mit all den Konten anzumelden, die unter Riot angelegt wurden. Im Gegensatz zu Riot ist bei ZOM jedoch noch keine Telefonie und keine Videotelefonie möglich. Ein weiterer Vorteil ist, daß die Verschlüsselung schon eingeschaltet ist und relativ einfach zu bedienen ist.

  • FluffyChat (extern)
    Dieser knuffige Client läuft u.a. auch auf dem Betriebssystem „UbuntuTouch“.

  • Syphon (extern)
    Dieser Client hat einen sehr interessanten Ansatz, denn hier soll neben der serverbasierten auch eine direkte, serverlose Kommunikation ermöglicht werden („P2P“). Allerdings ist Syphon noch in einem frühen Alphastadium und deshalb noch nicht für den tatsächlichen Produktiveinsatz geeignet. Basis hierfür ist https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix (extern).

The Grid

Ein paar Matrix-Entwickler haben sich abgespalten und wollen mit „The Grid“ (extern) den Fokus auf mehr Datenschutz legen.

„The Grid“ strebt folgende Ziele an:

  • Lösung des Problems, das ursprünglich durch das Matrix-Protokoll identifiziert wurde, fragmentierte Kommunikation, Einbeziehung einer sozialen Sichtweise
  • Einfache Client-Implementierungen, und föderierte Serverkommunkation, die die Hauptlast trägt
  • Dezentralisierte Datenspeicherung, verteilt auf die teilnehmenden Server
  • Entwickelt zur Vermeidung von Zentralisierung und/oder Monopolbildung

“Matrix’s ideals are Openness, Decentralization and Encryption while The Grid’s ideals are Freedom, Privacy and Security.”

Quelle: https://gitlab.com/thegridprotocol/home/blob/master/docs/overview.md (extern)

Sonstiges

Fazit

Trotz aller kritischen Punkte hat Matrix seine guten Seiten wird seinen Platz finden.

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

Zum Systemvergleich von Matrix und Jabber(XMPP): >> hier <<

Matrix Logo