Matrix

- Lesezeit: 33 Minuten / ganze Rubrik: 76 Minuten -

Provider-independent chat based on the protocol “Matrix” is a recommendation in the Quick Overview!

Still needs to be translated …

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

Matrix als ‘die’ Lösung

Matrix sieht sich selbst als die zentrale Lösung für Interoperabilität - und zum Geschäftsmodell gehört, dass durch unterschiedliche Brücken (s.u.) möglichst vielen anderen Systemen (extern) erreichen:

An important idea in Matrix is Interoperability. … We refer to the connection to other platforms as bridging.

Dieser Gedankenwelt folgend formuliert Matrix das z.B. wie folgt:

“Mit dem Kommunikationsprotokoll Matrix sollen Nutzer – unabhängig der jeweiligen App – miteinander kommunizieren können.” („Web3 Summit“ im Mai 2020)

Das hört sich super an, aber was bedeutet das tatsächlich und in der Praxis?

Es erfolgt immer eine Umleitung über Matrix, eine direkter Nachrichtenaustausch zwischen den angebundenen „Ziel“-Systemen gibt es nicht. In der Folge findet je nach Ausführung der Brücke (s.u.) eine Anreicherung von Metadaten im Matrix-Universum statt, obwohl Nutzer dort überhaupt keine Chatkonten eröffnet haben. Und sobald der Begriff „Interoperabilität“ im Marketing verwendet wird, sollte hintefragt werden, was darunter konkret verstanden wird.

Querverweise: Gedanken zur „Interoperabilität“ und Meinung zu Matrix

Gründe für die Entwicklung von Matrix

The Matrix team used XMPP (Openfire, ejabberd, spectrum, asmack, XMPPFramework) for IM before starting to experiment with open HTTP APIs as an alternative in around 2012 …

The main issues with XMPP that drove us in this direction as of 2012 were:

  • Not particularly web-friendly - you can’t easily speak XMPP from a web browser. N.B. Nowadays you have options like XMPP-FTW and Stanza.io that help loads with letting browsers talk XMPP_ _Single logical server per MUC is a single point of control and availability. MUCs can be distributed over multiple physical servers, but they still sit behind a single logical JID and domain. FMUC improvesthis with a similar approach to Matrix, but as of Oct 2015 there are no open source implementations. The MIX XMPP extension also aims to address this limitation.
  • History synchronisation is very much a second class citizen feature
  • Bridging to other protocols and defragmenting existing communication apps and networks is very much a second class citizen feature
  • Stanzas aren’t framed or reliably delivered without extensions. See wiki.xmpp.org for an XMPP take on this
  • Multiple device support is limited. Carbons and MAM aim to resolve this
  • Baseline feature set is so minimal that fragmentation of features between clients and servers is common, especially as interoperability profiles for features have fallen behind (as of July 2015)
  • No strong identity system (i.e. no standard E2E PKI, unless you count X.509 certs, which are questionable)
  • Not particularly well designed for mobile use cases: push; bandwidth-efficient transports. Since the time of writing a Push XEP has appeared, and wiki.xmpp.org states that XMPP is usable over a 9600bps + 30s latency link.

This said, 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.

We think of Matrix and XMPP as being quite different; at its core Matrix can be thought of as an eventually consistent global JSON db with an HTTP API and pubsub semantics - whilst XMPP can be thought of as a message passing protocol. You can use them both to build chat systems; you can use them both to build pubsub systems; each comes with different tradeoffs. Matrix has a deliberately extensive ‘kitchen sink’ baseline of functionality; XMPP has a deliberately minimal baseline set of functionality. If XMPP does what you need it to do, then we’re genuinely happy for you :) Meanwhile, rather than competing, an XMPP Bridge like Skaverat’s xmpptrix beta or jfred’s matrix-xmpp-bridge or Matrix.org’s own purple-matrix has potential to let both environments coexist and make the most of each other’s benefits.

Quelle: https://web.archive.org/web/20180711050333/https://matrix.org/docs/guides/faq.html (extern)
Querverweis: Kritik

Konzept

Bei Matrix werden Daten nicht nur von einem Server sondern jeweils von allen Servern der in der Gruppe bzw. bei dem Gespräch beteiligten Personen (Gruppe) gespeichert. Des Weiteren ist das Bereitstellen von “Brücken” zu anderen Systemen ist ein wesentlicher Punkt, mit dem Matrix interoperabel sein möchte.

Durch die auf alle beteiligten Servern verteilte Daten besteht eine gewisse 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 „chatten über git“ vorstellen. Natürlich ist das nicht tatsächlich „git“ - aber das Prinzip ist das Selbe und deshalb für das Verständnis hilfreich.

Die Ausfallsicherheit von Chaträumen wird durch einen höheren Ressourcenbedarf erkauft. Ausfallsichere Chaträume sind insbesondere für Firmen, Unternehmen, Behörden interessant.

Bezüglich des Konzepts bzw. der erfordelichen Ressourcen hat sich der Gründer/Mitentwickler/Direktor Hodgson persönlich in einem Blog-Kommentar (extern) so geäußert:

The fact that Matrix is using so much resources for a single user is because it’s a message store, not a messaging protocol like XMPP. If you join loads of busy rooms, the rooms get replicated onto your server. So a single busy user can easily use gigabytes of disk space. We’re improving the efficiency, but in the end one enthusiastic user can use way more space than thousands of users who just DM each other.

Das Protokoll ist 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 das sehr gut integrierte „Jitsi“ und BigBlueButton (BBB). 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.

Im Juli 2020 wurde der Matrix-Referenz-Client „Riot“ (der Messenger), New Vector (der Firma hinter Riot) und Modular (Webhosting für Matrix-Server) in „Element“ unbenannt. (Quelle: Wikipedia)

Quellen (alle englischsprachig):

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 (Twitter-Eintrag vom 21.11.2019 (extern)) ü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….“

Zum Verschlüsselungsprotokoll von Matrix gibt es eine gute Ausführung/Beschreibung (extern; englisch).

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 oder wenn das firmeninterne Regelungen erforderlich machen.

Grenzen der Matrix-Verschlüsselung

Nachfolgende Punkte beschreiben die Grenzen von Megolm (extern):

  • Wiederholungen von Nachrichten
    Eine Nachricht kann mehrere Male erfolgreich entschlüsselt werden. Das bedeutet, dass ein Angreifer eine Kopie einer alten Nachricht erneut senden kann, und der Empfänger wird sie als als neue Nachricht behandeln.
    Um dies abzuschwächen, wird empfohlen, dass Anwendungen die Ratchet-Indizes und Nachrichten mit einem Ratchet-Index, den sie bereits entschlüsselt haben, abzulehnen, die sie bereits entschlüsselt haben.

  • Fehlende Konsistenz des Protokolls
    In einer Gruppenkonversation gibt es keine Garantie, dass alle Empfänger die gleichen Nachrichten erhalten haben. Befindet sich Alice beispielsweise in einer Unterhaltung mit Bob und Charlie beteiligt ist, könnte sie unterschiedliche Nachrichten an Bob und Charlie senden, oder sie könnte einige Nachrichten an Bob, aber nicht an Charlie, oder umgekehrt.
    Dies zu lösen, ist im Allgemeinen ein schwieriges Problem, insbesondere in einem Protokoll, das nicht die ordnungsgemäße Zustellung von Nachrichten garantiert. Dies bleibt vorerst Gegenstand von zukünftigen Forschung.

  • Fehlende Rückwärtsverschwiegenheit
    Rückwärtige Geheimhaltung (auch “future secrecy” oder “post-compromise security” genannt) ist die Eigenschaft, daß ein Angreifer bei einer Kompromittierung der aktuellen privaten Schlüssel keine zukünftige Nachrichten in einer bestimmten Sitzung nicht entschlüsseln kann. Mit anderen Worten, wenn man einer bereits erfolgten Kompromittierung rückwärts betrachtet, sind aktuelle Nachrichten immer noch geheim. Megolm an sich hat diese Eigenschaft nicht: Sobald der Schlüssel einer Megolm Sitzung kompromittiert ist, kann der Angreifer jede Nachricht entschlüsseln, die die mit einem Schlüssel verschlüsselt wurde, der aus den kompromittierten oder nachfolgenden Ratchet Werten abgeleitet wurde.
    Um dies abzuschwächen, sollte die Anwendung sicherstellen, dass Megolm-Sitzungen nicht unendlich lange verwendet werden. Stattdessen sollte sie in regelmäßigen Abständen eine neue Sitzung starten, mit neuen Schlüsseln, die über einen sicheren Kanal ausgetauscht werden.

  • Teilweises Vorwärtsgeheimnis
    Vorwärtsgeheimnis (auch “perfektes Vorwärtsgeheimnis” genannt) ist die Eigenschaft, dass ein Angreifer, wenn die aktuellen privaten Schlüssel kompromittiert werden, kann ein Angreifer die vergangenen Nachrichten in einer bestimmten Sitzung entschlüsseln kann. Mit anderen Worten, wenn man in die Zukunft blickt und eine einer möglichen zukünftigen Kompromittierung, sind die aktuellen Nachrichten geheim.
    In Megolm behält jeder Empfänger eine Aufzeichnung des Ratchet-Wertes bei, die es ihm ermöglicht alle Nachrichten zu entschlüsseln, die in der Sitzung nach dem entsprechenden Zeitpunkt in der Konversation. Wenn dieser Wert kompromittiert wird, kann ein Angreifer auf ähnliche Weise Nachrichten entschlüsseln, die mit einem Schlüssel verschlüsselt wurden, der von dem kompromittierten oder nachfolgenden Ratchet-Werten abgeleitet wurden. Dies ergibt eine “teilweise” Vorwärtgeheimhaltung.
    Um dieses Problem zu entschärfen, sollte die Anwendung dem Nutzer die Möglichkeit bieten historische Konversationen zu verwerfen, indem alle gespeicherten Ratchet-Werte vorwärts gespult werden oder die Sitzungen ganz zu verwerfen.

  • Abhängigkeit von einem sicheren Kanal für den Schlüsselaustausch
    Der Entwurf des Megolm-Ratchet beruht auf der Verfügbarkeit eines sicheren Peer-to-Peer-Kanals für den Austausch von Sitzungsschlüsseln. Jede Schwachstelle im dem zugrunde liegenden Kanal werden wahrscheinlich verstärkt, wenn sie auf den Megolm Sitzungsaufbau. Ist der Peer-to-Peer-Kanal beispielsweise anfällig für einen unbekannten Key-Share anfällig ist, wird die gesamte Megolm-Sitzung in ähnlicher Weise anfällig

Datenschutz

Aktuell gibt es noch keine deutschen Allgemeinen Geschäftsbedingungen (AGB). In den “privacy notice” (extern) 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.”

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.

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

The Grid

Mit „The Grid“ (extern) gibt es von ein paar ehemaligen Matrix-Entwicklern 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.“

„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)

Brücken

Für Matrix sind Brücken („Matrix-Bridges“) elementar und ein Teil des Geschäftsgrundlage (wobei das für alle Teammessenger - also auch Mattermost, Rocket.Chat und Zulip gilt).

Es gibt verschiedene Brücken, um mit anderen Systemen Nachrichten auszutauschen und man möchte so für Interoperabilität sorgen. 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. Der Onlinestatus als wesentliches Merkmal von Chat kann z.B. natürlich nicht übertragen werden.

Querverweis: Sind Brücken und deren Nutzung legal?

Leider ist es auch so, daß Brücken nicht an Standards gebunden sind und vom Betreiber nach Belieben eingerichtet und verändert werden können. Auch können zum Beispiel Nachrichteninhalte nicht nur 1:1 transportiert, sonden auch auf dem Transportweg geändert werden, um so nativen Matrix-Nutzern ein angenehmeres Nutzererlebnis zu bieten. (Querverweis: Kritikpunkt ‘Datenintegrität’ )

Arten von Brücken

  • Portalräume
    Diese steuern Teile des Raum-Alias-Namensraumes. Zum Beispiel entspricht #freenode_#channelname:matrix.org dem #channelname auf Freenode. Auf diese Weise können Matrix-Benutzer auf transparente Weise IRC-Kanälenauf Freenode beitreten. Portalräume werden in der Regel von der Seite des entfernten Netzes verwaltet, in dem der Raum liegt.

  • Plumbed-Räume
    Diese Räume werden durch die Konfiguration einer Bridge (die von jedem ausgeführt werden kann) in einen oder mehrere bestimmte Remote-Räume “geplumpt” [keine Ahnung, was das auf deutsch heißt]. Zum Beispiel ist #matrix:matrix.org mit #matrix auf Freenode verbunden, matrixdotorg/#matrix auf Slack usw. Die Zugriffskontrolle für Matrix-Benutzer wird notwendigerweise von der Matrix-Seite des Raums verwaltet. Dies ist nützlich, um mit Matrix verschiedene Gemeinschaften miteinander zu verbinden.

  • Bridgebot-Stil
    In diesem Fall werden Nachrichten in beide Richtungen von einem Bot [Automatismus, der wie ein Roboter funktioniert und automatisierte Aufgaben übernimmt] übermittelt, der sich auf der jeweiligen Plattform befindet. Dies ist eine suboptimale Erfahrung, da Metadaten verloren gehen. Beispielsweise könnten alle Nachrichten von demselben Bot gesendet werden, wobei dem Nachrichtentext jedoch der Name des ursprünglichen Absenders vorangestellt wird.

  • Puppeting
    Löst die Probleme des Bot-basierten Bridging durch “Puppeting” [=Schattennutzer], d. h. die Steuerung eines Benutzers auf der anderen Seite der Brücke. Das bedeutet, dass einheimische Benutzer die Nachrichten so sehen, als ob sie vom richtigen Absender gesendet würden. Doppeltes Puppeting bedeutet, dass dies in beide Richtungen der Brücke erfolgt. Dies ist die bevorzugte Art der Implementierung einer Matrix-Brücke.

Es gibt viele theoretisch verfügbare Brücken - allerdings werden von den beiden eng verbundenen Unternehmen matrix.org und element.io nur manche davon aktiv angeboten und das sind teilweise sogar unterschiedliche. Das Marketing dazu ist nicht leicht zu durchschauen, denn es scheint keine gemeinsame Positionierung sondern unterschiedliche Priorisierungen von angebotenen Brücken seitens matrix.org und element.io zu geben. Brücken zu populären aber geschlosseenen Plattformen wie WhatsApp werden angepriesen - die Schnittstelle zum Standardprotokoll für Chat (XMPP) dagegen ist aktuell immer noch im experimentellen Stadium und geht (vielleicht deshalb?) im Marketing unter.

(Querverweis: Kritikpunkt ‘Unklare Positionierung’ )

Eine weitere Beschreibung im Netz zu Brücken: blog.novatrend.ch (extern)

XMPP-Brücke

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.

Mit „Bifröst/libpurple“ gibt es eine Brücke, die auf der FOSDEM 2020 (extern) vorgestellt wurde:

„… and demonstrate high quality bridging with XMPP, Slack, Discord, WhatsApp, and more!

Was wird konkret unter „high quality“ verstanden? Zumindest passt der für diese Brücke gegebene 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.“ nicht ganz zu „high quality“.

„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.“ (Originaltext Stand 04/2022)

Technische Details zu Bifröst finden sich bei: https://github.com/matrix-org/matrix-bifrost/wiki/Address-syntax (extern). Zudem bietet matrix.org eine öffentliche Instanz der Brücke an:

„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. …“_ (Stand 02.05.2020)

Es 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 den zentralen Dienst matrixuser_matrixserver.tld@matrix.org erreichen.

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

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

Einschränkungen:

  • 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 api 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.

Ein anderes Brücken-Projekt https://matrix.org/docs/projects/as/matrix-xmpp-bridge (extern) wurde 2019 eingestellt.

WhatsApp

Matrix hat eine Brücke zum Chatstandard XMPP mit dem Namen Bifröst/Libpurple und vermarket diese auch. Mit dem Projekt Mautrix (extern) gibt es weitere Möglichkeit. Die aktuell verfübaren Funktionen (extern) sind beeindruckend.

Alle Anbieter/Nutzer, die die Web-Schnittstelle von WhatsApp für ihre Zwecke vewenden müssen jedoch damit rechnen, daß diese (mißbräuchliche) Vewendung von Meta/Facebook durch Änderungen schnell unterbunden werden kann.

Querverweis: Rechtmäßigkeit von Brücken

Weitere

  • Mit Matterbridge (extern) sind ebenfalls sehr viele Brücken zwischen unterschiedlichsten Systemen möglich.
  • Dieses Projekt (extern) beschäftigt sich damit, per Shell-Scripten auf Matrix zuzugreifen.

Nutzung

Anleitungen

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.

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“, mit dem eine eigene Matrix-Insel (ohne Föderation und natürlich ohne Interoperabilität) betrieben werden kann. Die Serversoftware kann sogar auf einem Mini-Computer wie dem Raspberry Pi installiert werden.

Als Nachfolger von Synapse wird seit 2020 an „Dendrite“ gearbeitet. Diese Serversoftware ist nicht in Phyton sondern in der Programmiersprache „Go“ geschrieben. Mit Dendrite sollen die Effizienz, die Zuverlässigkeit und die Skalierbarkeit verbessert werden (vgl. https://gnulinux.ch/matrix-von-synapse-zu-dendrite (extern)) - allerdings ist Dendrite noch im Beta-Stadium.
Eine schöne Anleitung gibt es hier: https://ersei.net/en/blog/setting-up-matrix-dendrite (extern; englisch)

Synapse: https://github.com/matrix-org/synapse (extern; englisch)
Dendrite: https://github.com/matrix-org/dendrite (extern; englisch)
Conduit: https://conduit.rs (extern; englisch)

Verbindungen

Einen Überblick über die Serverlandschaft bei Matrix bietet die Seite https://voyager.t2bot.io/#/graph (extern).

Voyager is a bot that travels through Matrix trying to find new rooms. It does this by sitting in rooms and waiting for someone to mention another room, at which point it tries to join that room. Each new room it discovers is mapped to a public graph.

Matrix-Server-Verbindungen
Im zentralen Bereich sind die Server mit vielen Verbindungen - weiter außen die mit weniger Verbindungen und am Randbereich der Scheibe die Server ohne Verbindungen.
Matrix-Server-Verbindugnen (zentraler Ausschnitt)
Die meisten Verbindungen laufen bei den zwei großen Instanzen „Matrix.org“ und „Element.im“(=„Riot.im“) zusammen.

Serverlisten

Eigener Server

Tipp: Ressourcenverbrauch reduzieren: Matrix-Synapse nativ auf Ubuntu verbraucht viel RAM und CPU (extern)

Weitere:

  • 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.
  • Tipp 3: Datenbank komprimieren:
    • Stuff that no longer needs to be kept around
    • Optimizing synapse cache
    • Table bloat & Index bloat in PostgreSQL

Quelle: https://levans.fr/shrink-synapse-database.html (extern, englisch)

Weitere Serverinfos

Clients

Ein Pluspunkt von Matrix ist, dass es für so gut wie alle Betriebssysteme funktionierende Klienten (Programme/Apps) (extern, englisch). Aber Vorsicht: Viele der auf der Seite aufgeführten Apps sind noch im Alpha- oder Betastadium befinden oder die nicht mehr weiterentwicklet werden (den Status der einzelnen Projekte sieht man nicht mehr sofort auf der Übersichtsseite - jetzt bitte eine Ebene tiefer in den Details schauen).

  • Element (PlayStore: USK 18) ist der quasi Referenzclient mit der größen Verbreitung. Es ist nur 1 Chatkonto möglich; die Desktopanwendung basiert auf Electron.

  • FluffyChat (extern) (PlayStore: USK 18)
    Dieser knuffige Client läuft u.a. auch auf dem Betriebssystem „UbuntuTouch“. Einzige Anwendung ohne Electron für den Desktop, da die anderen sich noch im Entwicklungsstadium (Alpha/Beta) befinden oder nicht mehr weiterentwickelt werden. *

  • SchildiChat (extern) (PlayStore: USK 0)

  • Syphon (extern) (PlayStore: USK 0)
    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 p2p-matrix (extern) / pinecone-overlay-network (extern).

  • Zom (extern) (PlayStore: USK 0)
    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 Element angelegt wurden. Im Gegensatz zu Element ist bei ZOM keine Telefonie und keine Videotelefonie möglich. Ein weiterer Vorteil ist, daß die Verschlüsselung schon eingeschaltet ist und relativ einfach zu bedienen ist.
    Quellcode: https://github.com/zom (extern)

*) Andere Electron-freie Desktop-Clients als FluffyChat sind nicht zu empfehlen:

  • Fraktal (extern): Maturity: Beta
  • NeoChat (extern): Maturity: Beta
  • Nheko (extern): Maturity: Beta
  • Seaglass (extern): Maturity: Not actively maintained / At this stage it is early in development and stands a good chance of being buggy and unreliable.
  • Spectral (extern): Maturity: Alpha

Chaträume

Da alles als “Raum” betrachtet/behandelt wird, können problemlos (versehentlich) mehrere Räume mit demselben Kontakt geöffnet werden.

Für Chaträume (alles sind Räume) gibt es verschiedene Versionen (extern), da sich Raumspezifikationen fortentwickeln.


Finanzierung

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

  • Finanzierung:
    Von 2014 bis 2017 wurde Matrix von Amdocs (extern) (Morris Kahn, Israel) finanziert, auch später gab es noch Kontakte. Mehr zu Amdocs >> hier <<.
    Bei Golem (extern) ist dazu zu finden:

… Die beiden Gründer des Projekts, Matthew Hodgson und Amondine Le Pape, sowie ein kleines Kernentwicklerteam werden aber vom US-Softwaredienstleister Amdocs bezahlt, der auch die Rechte an Riot hält. Amdocs habe bei der Entwicklung natürlich ein kommerzielles Interesse, bestätigt Hodgson. Ziel sei vor allem, Hosting- und Supportdienste für Geschäftskunden zu entwickeln und so die Matrix-Plattform zu vermarkten. … Ein weiteres Geschäftsfeld für Amdoc könnten kostenpflichtige Bridges für Geschäftsanwendungen sein.

Darauf gründeten die Matrix-Entwickler ihre eigene Firma New Vector Limited für die Finanzierung.

Die Investmentgruppe “Notion Capital” hat sich auf europäische Firmen spezialisiert, die Software-Anwendungen über das Internet, d.h. als Service, anbieten oder als Lizenzmodell haben („Notion Capital is a VC firm focused on European SaaS and Cloud“). Der Investor hat sich erstmals 2017 bei Element.io engagiert und ins Portfolio mit aufgenommen: https://www.notion.vc/portfolio/element (extern). Über Notion werden auch immer wieder Arbeitsplätze bei Element.io angeboten.

Beteiligungen Matrix

  • Jan 29, 2018: Matrix raised $5,000,000 from Status.im

Gesamt (extern):
Matrix has raised a total of $5M in funding over 1 round. This was a Venture - Series Unknown round raised on Jan 29, 2018. Matrix is funded by Status.im.

Beteiligungen New Vector

Gesamt (extern):

  • Element has raised a total of $48.1M in funding over 5 rounds. Their latest funding was raised on Jul 26, 2021 from a Series B round.
  • Element is funded by 8 investors. Metaplanet Holdings and Notion Capital are the most recent investors.
  • Element has acquired Gitter on Sep 30, 2020.

Blockchain und Kryptowährung

2018 investierte der Blockchain-Messenger Status.im, der sehr eng mit der Kryptowährung „Etherum“ verbunden ist, 5 Millionen Dollar in Matrix.org (und weitere 5 Mio $ in New Vector):

Status invests $5 million in Matrix to create a blockchain messaging superpower

Enter Status, the mobile Ethereum client built entirely on peer-to-peer technologies. Today, Status has announced a significant investment in New Vector, the company behind Matrix.org, the open standard for secure and decentralized communication.

How significant? Status is making a $5 million investment in New Vector, effectively creating a partnership between two of the industry’s largest decentralized messaging platforms.

Quelle: https://venturebeat.com/2018/01/29/status-invests-5-million-in-matrix-to-create-a-blockchain-messaging-superpower/

Im Direktorium der Stiftung ist (Stand 04/2022) auch die Firma Parity Technologies (extern) vertreten, die im Bereich Blockchaintechnologien tätig ist.


Strukturen

Begriffsverwendung:

Element ist die Bezeichnung sowohl für den Client, die Internetseite als auch Firmen. Die Internetseite lautet: https://element.io (extern) - https://vector.im (extern) wird auf element.io umgeleitet.

Lt. https://element.io/privacy (extern) kann im Regelfall ‘Element’ mit New Vector Ltd, New Vector SARL (extern) und Element Software Inc gleichgesetzt werden:

Where you read ‘Element’ or ‘we’ or ‘us’ below, it refers to Element, a trading name of New Vector Ltd., its French subsidiary: New Vector SARL, its U.S. subsidiary: Element Software Inc, and their agents.

Organisation und Firmen

  • Amdocs: Der Beginn von Matrix noch unter der Bezeichnung „Amdocs Unified Communications“ (extern)

  • The Matrix.org Foundation C.I.C. entwickelt und betreut das Matrix-Protokoll

  • NEW VECTOR LIMITED ist der weltweit größte Matrix-Hoster, ist der Eigentümer der eingetragene Marke “Element” und betreibt beispielsweise auch die Identitässerver Matrix.org und Vector.im bzw. ist der “Data Controller” für diese Dienste Quelle (extern). Die Seite https://element.io (extern) ist von New Vector.
    Registerauszug bei service.gov.uk (extern)

  • New Vector SARL Gesellschaft nach französischem Recht (zu den Aufgaben noch keine konkreten Informationen im Netz dazu gefunden)

  • ELEMENT SOFTWARE INC., USA
    Bei opencorporates.com (extern) bzw. nhcompanyregistry.com (extern) bzw. bizpedia.com (extern) werden insgesamt 11 [ELEMENT SOFTWAR INC. …] gefunden, von denen 3 als alt/inaktiv vermerkt sind. (Informationen zur Tätigkeit fehlen noch) …

  • PARITY TECHNOLOGIES LIMITED und Parity Technologies Deutschland GmbH, Berlin / Blockchain-Technologie (extern))

Beauftragte Unternehmen:

  • Wirtschaftskanzlei „King & Wood Mallesons“ (extern) in London: Postadresse für New Vector Limited
  • CT Corporation System / Wolters Cluwer (extern) (Der nach eignenen Angaben weltweit führende Anbieter von Lösungen für Legal Entity Management, Corporate Compliance und Due Diligence / führendene Gesellschaft für Lösungen zur Verwaltung von Rechtspersönlichkeiten): Eingetragener Vertreter für diverse ELEMENT SOFTWARE INC.

Personen

Gemeinsamkeiten

Sowohl M. Hodgson als auch A. La Pape sind als Direktoren sowohl bei Matrix.org als auch bei der Firma New Vector Limited (sowie den Tochterfirmen angestellt - eine gemeinsame Anzeige im Register jedoch bei beiden durch unterschiedliche Vornamen verhindert wird:

  • NEW VECTOR LIMITED: “Matthew Hodgson
  • THE MATRIX.ORG FOUNDATION C.I.C.: “Matthew James Hodgson
  • NEW VECTOR LIMITED: “Amandine LE PAPE
  • The MARTIX.ORG FOUNDATION C.I.C.: “Amandine Beatrice Marie LE PAPE

Schlimm? Nein - aber sehr interessant, da Direktoren bezahlt werden und eine gewisse Transparenz auch bezüglich der Verbindungen gegeben sein sollte.

Die enge Verbindung zeigen auch die Büros der sog. „juristischen Personen“, die direkt nebeneinander im selben Gebäude (14 Turnham Green Terrace Mews) liegen:

Die Postanschrift der New Vector Limited (“10 Queen Street Place, London, United Kingdom, EC4R 1AG”) ist die Adresse der internationalen Wirtschaftskanzlei „King & Wood Mallesons“ in London (Hauptsitz Hongkong), was bei internationalen Konzernen nicht unüblich scheint.
OpenStreetMap: Auf Karte anzeigen (extern)


Sonstiges

Fazit

Trotz allem:
Matrix ist eine sehr gute Lösung für verteilte Arbeit in Organisationen, Unternehmen oder Behörden! Im Gegensatz zu manch anderem Teammessenger wie z.B. Slack ist der komplette Quellcode offen und somit überprüfbar - auch ist eine systeminterne Föderation möglich, was Matrix zudem von Mattermost, Rocket.Chat und Zulip abhebt.

Ideal wäre eine noch bessere Unterstützung des internationalen Standards (XMPP). So könnten Unternehmen/Behörden intern die Vorteile von ausfallsicheren Chaträumen genießen - und trotzdem wäre ein standardisierter Austausch von Nachrichten von/nach außen möglich.

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

Matrix Logo