Matrix

- Lesezeit: 48 Minuten / ganze Rubrik: 91 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 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.

Inhalt:

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

Das Matrix-Team verwendete XMPP (Openfire, ejabberd, spectrum, asmack, XMPPFramework) für Instant Messaging, bevor es etwa 2012 begann, mit offenen HTTP-APIs als Alternative zu experimentieren.

Die Hauptprobleme mit XMPP, die uns ab 2012 in diese Richtung trieben, waren:

  • Nicht besonders webfreundlich - Sie können XMPP nicht einfach von einem Webbrowser aus nutzen.
  • Ein einziger logischer Server pro Mehrbenutzerchatraum ist ein einziger Punkt der Kontrolle und Verfügbarkeit. Mehrbenutzerchaträume können über mehrere physische Server verteilt sein, aber sie sitzen immer noch hinter einer einzigen logischen Chatadresee und Domain. Föderierte Mehrbenutzerchaträume (FMUC) improvisiert mit einem ähnlichen Ansatz wie Matrix, aber seit Oktober 2015 gibt es keine Open-Source-Implementierungen mehr. Die MIX-XMPP-Erweiterung zielt ebenfalls darauf ab, diese Einschränkung zu beheben.
  • Die Verlaufssynchronisierung ist eine Funktion zweiter Klasse.
  • Die Überbrückung zu anderen Protokollen und die Defragmentierung bestehender Kommunikationsanwendungen und -netze ist eine Funktion zweiter Klasse.
  • Stanzas werden ohne Erweiterungen nicht gerahmt oder zuverlässig ausgeliefert. Siehe wiki.xmpp.org für eine Stellungnahme von XMPP zu diesem Thema.
  • Die Unterstützung mehrerer Geräte ist begrenzt. Carbons und MAM zielen darauf ab, dies zu beheben.
  • Der grundlegende Funktionsumfang ist so minimal, dass eine Fragmentierung der Funktionen zwischen Clients und Servern üblich ist, zumal die Interoperabilitätsprofile für die Funktionen in Verzug geraten sind (Stand: Juli 2015).
  • Kein starkes Identitätssystem (d. h. keine standardmäßige E2E-PKI, es sei denn, Sie zählen X.509-Zertifikate, die fragwürdig sind)
  • Nicht besonders gut für mobile Anwendungsfälle konzipiert: Push; bandbreiteneffiziente Transporte. Seit dem Zeitpunkt der Erstellung dieses Artikels ist ein Push XEP erschienen, und wiki.xmpp.org gibt an, dass XMPP über eine Verbindung mit 9600bps + 30s Latenzzeit nutzbar ist.

Abgesehen davon ist der ganze Bereich XMPP vs. Matrix ziemlich subjektiv. Anstatt darüber zu streiten, welcher offene interoperable Kommunikationsstandard am besten funktioniert, sollten wir einfach zusammenarbeiten und alles miteinander verbinden. Je mehr Föderation und Interoperabilität, desto besser.

Wir betrachten Matrix und XMPP als recht unterschiedlich; im Kern kann man sich Matrix als eine letztendlich konsistente globale JSON-Datenbank mit einer HTTP-API und Pubsub-Semantik vorstellen - während man XMPP als ein Nachrichtenübertragungsprotokoll betrachten kann. Man kann beide verwenden, um Chatsysteme zu bauen; man kann beide verwenden, um Pubsub-Systeme zu bauen; jedes kommt mit unterschiedlichen Kompromissen. Matrix verfügt über eine absichtlich umfangreiche Grundausstattung an Funktionen, XMPP über eine absichtlich minimale Grundausstattung an Funktionen. Wenn XMPP das tut, was Sie brauchen, dann freuen wir uns wirklich für Sie :) In der Zwischenzeit hat eine XMPP-Brücke wie Skaverats xmpptrix beta oder jfreds matrix-xmpp-bridge oder Matrix.org’s eigene purple-matrix das Potential, beide Umgebungen nebeneinander existieren zu lassen und die Vorteile der jeweils anderen zu nutzen.

Maschinell übersetzt aus 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 gespeichert. Des Weiteren ist das Bereitstellen von “Brücken” zu anderen Systemen ist ein wesentlicher Punkt, mit dem Matrix einen Beitrag zur Interoperabilität leistet.

Durch die auf alle beteiligten Servern verteilte Daten besteht eine gewisse Ausfallsicherheit von Chaträumen.

Jede Konversation (egal ob 1:1, Gruppe oder Brücke zu irgendeinem anderen Protokoll) ist ein Raum. Dadurch läßt sich dann z.B. ein 1:1 Chat zu einer Gruppe machen oder auch umgekehrt. Man kann auch problemlos beliebig viele Räume mit einem Kontakt öffnen.

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.

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 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ärtsgeheimhaltung.
    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.

Englische “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.“

Quelle: Aus weitergeleiteter Information per E-Mail

„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 gebrückten Räumen

  • Portalräume
    Bridges können sich selbst als kontrollierende Teile des Raum-Alias-Namensraums registrieren, so dass Matrix-Benutzer entfernten Räumen auf transparente Weise beitreten können, wenn sie /join #freenode_#wherever:matrix.org oder ähnlich eingeben. Der resultierende Matrix-Raum wird in der Regel automatisch mit dem einzelnen entfernten Zielraum verbunden. Die Zugangskontrolle für Matrix-Benutzer wird in der Regel von der Seite des entfernten Netzwerks aus verwaltet. Dies wird als Portalraum bezeichnet und ist nützlich, um in entfernte Räume zu springen, ohne dass irgendeine Konfiguration erforderlich ist - mit Matrix als “Türsteher” für das entfernte Netzwerk.
    Vorherige Beschreibung:
    Portalräume 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
    Alternativ kann ein bestehender Matrix-Raum in einen oder mehrere spezifische Remote-Räume eingebunden werden, indem eine Bridge konfiguriert wird (die von jedem ausgeführt werden kann). Zum Beispiel ist #matrix:matrix.org mit #matrix auf Freenode verbunden, matrixdotorg/#matrix auf Slack, usw. Die Zugangskontrolle für Matrix-Benutzer wird notwendigerweise von der Matrix-Seite des Raums verwaltet. Dies ist nützlich für die Verwendung von Matrix, um verschiedene Gemeinschaften miteinander zu verbinden.

    Das Migrieren von Räumen zwischen einem Portal- und einem ‘Plumbed’-Raum ist derzeit ein bisschen chaotisch , da es noch keine Möglichkeit für Benutzer gibt, Portalräume zu entfernen, sobald sie erstellt wurden, so dass Sie mit einer Mischung aus Portal- und Plumbed-Benutzern enden können, die in einem Raum verbunden sind, was sowohl aus der Matrix- als auch aus der Nicht-Matrix-Sicht seltsam aussieht. https://github.com/matrix-org/matrix-appservice-irc/issues/387 (extern) verfolgt dies.

Arten von Brücken

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.\ Es wäre interessant zu erfahren, wie viele Entwicklungstage/-stunden und wie viel der aufgebrachten Gelder in die verschiedenen Arten von Brücken investiert werden:

  • Bridgebot-basierte Brücken
    Die einfachste Möglichkeit, Nachrichten mit einem entfernten Netzwerk auszutauschen, besteht darin, dass sich die Bridge mit einem oder mehreren vordefinierten Benutzern, den so genannten Bridge-Bots, in das Netzwerk einloggt - typischerweise MatrixBridge oder MatrixBridge[nnn] usw. genannt. Diese leiten den Verkehr im Namen der Benutzer auf der anderen Seite weiter, aber das ist eine schreckliche Erfahrung , da alle Metadaten über die Nachrichten und Absender verloren gehen . So funktioniert die telematrix matrix<->telegram-Brücke derzeit.
    Vorherige Beschreibung:
    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.
    Die Probleme des Bot-basierten Bridging werden durch “Puppeting” [=Schattennutzer] gelöst. Das heißt, die Steuerung eines Benutzers auf der anderen Seite der Brücke. Das wiederum 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.

  • Bot-API (auch bekannt als virtueller Benutzer) basierte Brücken Einige entfernte Systeme unterstützen die Idee, Nachrichten von “falschen” oder “virtuellen” Nutzern einzuschleusen, die verwendet werden können, um die Nutzer auf der Matrix-Seite als einzigartige Entitäten im entfernten Netzwerk darzustellen. Mit den eingehenden Webhooks von Slack können beispielsweise bei Bedarf Remote-Bots erstellt werden, mit denen Matrix-Benutzer kosmetisch korrekt als virtuelle Benutzer in der Zeitachse anzeigen. Die daraus resultierenden virtuellen Benutzer sind jedoch keine echten Benutzer auf dem entfernten System, haben also keine Präsenz/kein Profil und können keine Tabs ausfüllen oder Direktnachrichten senden usw. Sie haben auch keine Möglichkeit, Typisierungsbenachrichtigungen oder andere umfassendere Informationen zu erhalten , die nicht über Bot-APIs verfügbar sind. Dies ist, wie die aktuelle Matrix-App-Service-Slack-Brücke funktioniert.

  • Einfache Marionettenbrücke
    Dabei handelt es sich um eine umfassendere Form des Bridging, bei der sich die Bridge beim Remote-Dienst anmeldet, als wäre sie ein echter 3rd-Party-Client für diesen Dienst. Folglich muss der Matrix-Benutzer bereits über ein gültiges Konto auf dem entfernten System verfügen. Im Gegenzug “verkörpert” der Matrix-Benutzer seinen entfernten Benutzer, so dass andere Benutzer auf dem entfernten System nicht einmal wissen, dass sie mit einem Benutzer über Matrix sprechen. Die gesamte Semantik des entfernten Systems steht der Bridge zur Verfügung, um sie in Matrix freizugeben. Allerdings muss die Bridge den Authentifizierungsprozess für die Anmeldung des Benutzers bei der entfernten Bridge durchführen.
    Dies ist im Wesentlichen die Art und Weise, wie die aktuelle matrix-appservice-irc-Brücke funktioniert (wenn Sie sie so konfigurieren, dass Sie sich mit Ihrem “echten” IRC-Nickname beim entfernten IRC-Netzwerk anmelden). matrix-appservice-gitter wird erweitert, um sowohl den Puppet- als auch den Bridgebot-basierten Betrieb zu unterstützen. So funktioniert die experimentelle matrix-appservice-tg-Brücke.
    In Zukunft sollen alle Brücken zumindest einfach, wenn nicht sogar doppelt gepuppt sein.

  • Doppelte Marionettenbrücke
    Eine einfache “Puppeted Bridge” ermöglicht es dem Matrix-Benutzer, sein Konto in seinem entfernten Netzwerk zu steuern. Idealerweise sollte dieses Puppeting jedoch in beide Richtungen funktionieren, d. h. wenn sich der Benutzer z. B. bei seinem nativen Telegram-Client anmeldet und Unterhaltungen beginnt, Nachrichten sendet usw., sollten diese in Matrix zurückgespiegelt werden, als ob der Benutzer dies dort getan hätte. Dazu muss die Brücke in der Lage sein, die Matrix-Seite der Brücke im Namen des Benutzers zu steuern.
    Dies ist der heilige Gral der Überbrückung, da sowohl das Matrix-Konto als auch das Konto eines Dritten in ihren jeweiligen Netzwerken korrekt dargestellt werden, wobei alle Metadaten des Benutzers intakt sind. Dies steht im Gegensatz zu einem Relaybot, der als ein von dem Benutzer, den er vertritt, getrennter Benutzer erscheinen würde.
    Es gibt mehrere Hindernisse für die ordnungsgemäße Implementierung von Double-Puppeted-Bridges. Auf der Matrix-Seite benötigen wir eine elegante Möglichkeit, die Bridge mit Matrix als Matrix-Benutzer zu authentifizieren (was eine Art von scoped access_token-Delegation erfordert). Im Netz von Drittanbietern gibt es besondere Probleme , die von den Einschränkungen des jeweiligen Netzes abhängen. Viele Netzwerke von Drittanbietern sind beispielsweise nicht in der Lage, andere Matrix-Benutzer zu repräsentieren als denjenigen, der als Puppe angemeldet ist (siehe Hybrid-Relaybot).
    matrix-puppet-bridge ist ein Gemeinschaftsprojekt, das versucht, die Entwicklung von Double-Puppet-Bridges zu erleichtern, und das dies, ohne Bridgebot, für mehrere Netzwerke getan hat. Ein Nachteil ihres Ansatzes ist die Annahme, dass eine Person die Bridge auf ihrem eigenen Homeserver betreibt und so das Problem der gemeinsamen Nutzung von Anmeldeinformationen auf einem gemeinsamen Homeserver umgeht.

  • Hybride Relaybot-Puppenbrücke
    Bei dieser Art von Brücke handelt es sich um eine kombinierte Einzel- oder Doppelpuppenbrücke, die versucht , das Problem der Vertretung anderer Benutzer mit Hilfe der Bridgebot-Technik zu lösen. mautrix/telegram arbeitet auf diese Weise.

  • Server-zu-Server-Überbrückung
    Einige Protokolle (IRC, XMPP, SIP, SMTP, NNTP, GnuSocial usw.) unterstützen Föderation - entweder offen oder geschlossen. Die eleganteste Art der Überbrückung zu diesen Protokollen wäre es, die Brücke als Server an der Föderation teilnehmen zu lassen und den gesamten Namensraum direkt in Matrix zu überbrücken.
    Uns ist niemand bekannt, der dies bisher getan hat.
    [Anmerkung: Das ist nicht die Aufgabe der Anderen. Sollte das nicht der heilige Gral der Überbrückung sein, statt der Doppelpuppenbrücke? Bitte verwenen Sie hier etwas von dem investierten Geld, um einen xmpp-Server direkt in den Matrix-Server zu integrieren, um Interoperabilität zu erreichen!]

  • Einseitige Überbrückung
    Eine einseitige Überbrückung ist selten, kann aber verwendet werden, um eine Brücke vom entfernten System zur Matrix darzustellen. Dies ist häufig der Fall, wenn das entfernte System das Versenden von Nachrichten nicht zulässt oder einfach nicht in der Lage ist, das Versenden außerhalb seines Systems zu verarbeiten. Die vom entfernten System überbrückten Benutzer erscheinen oft als virtuelle Benutzer in Matrix, wie im Fall von matrix-appservice-instagram.

  • Seitenwagenbrücke
    Schließlich: Bei den oben beschriebenen Arten der Überbrückung wird davon ausgegangen, dass Sie den Gesprächsverlauf des entfernten Systems in Matrix synchronisieren, so dass er dezentralisiert und mehreren Benutzern innerhalb des größeren Matrix-Netzwerks zugänglich sein kann.
    Dies kann zu Problemen führen, wenn das entfernte System über beliebig komplizierte Berechtigungen (ACLs) verfügt, die den Zugriff auf die Historie steuern, die dann korrekt mit dem ACL-Modell von Matrix synchronisiert werden müssen, ohne dass Sicherheitsprobleme wie z. B. Wettrennen auftreten. In der IRC-Bridge gibt es bereits einige Probleme damit, da die Sichtbarkeit des Verlaufs für +i und +k Kanäle sorgfältig mit den Matrix-Räumen synchronisiert werden muss. Es kann auch zu Problemen mit anderen netzspezifischen Funktionen kommen, die noch keine gleichwertige Darstellung im Matrix-Protokoll haben (z. B. ephemere Nachrichten oder Nur-Op-Nachrichten - obwohl das wohl eine Art von ACL ist).
    Eine Lösung könnte darin bestehen, eine völlig andere Architektur der Überbrückung zu unterstützen, bei der die Matrix-Client-Server-API direkt auf den entfernten Dienst abgebildet wird, was bedeutet, dass ACL-Entscheidungen an den entfernten Dienst delegiert werden und Unterhaltungen nicht in die breitere Matrix einfließen. Dies bedeutet, dass die Bridge effektiv als reiner 3rd-Party-Client für das Netzwerk verwendet wird (ähnlich wie Bitlbee). Die Bridge steht nur einem einzigen Benutzer zur Verfügung, und Unterhaltungen können nicht mit anderen Matrix-Benutzern geteilt werden, da es sich nicht um tatsächliche Matrix-Räume handelt (eine andere Lösung könnte die Verwendung von Active Policy Servern sein, um ACLs für einen Raum zu zentralisieren und zu delegieren).
    Dies ist im Wesentlichen ein völlig anderes Produkt als der Rest von Matrix, und obwohl es eine Lösung für einige besonders schmerzhafte ACL- Probleme sein könnte, konzentrieren wir uns vorerst auf Nicht-Seitenwagen-Brücken.

Quelle: https://matrix.org/docs/guides/types-of-bridging (extern; 01.08.2022)

Es fällt auf, dass oft über Probleme und in der Möglichkeitsform gesprochen wird. Das ist auch der Grund, warum Brücken oft als alte Krücken bezeichnet werden.
Querverweise: Kritikpunkt: ‘Brücken’ und Interoperabilität: ‘Brücken’

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

XMPP-Brücke

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 nicht ganz zu „high quality“: „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.“

„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) und https://aria-net.org/SitePages/Portal/Bridges.aspx (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:

  • Unverschlüsselte Nachrichten zwischen Matrix- und XMPP-Räumen

  • Hinzufügen einzelner XMPP-Nutzer zu 1:1 Unterhaltungen (also unabhängig von Gruppen/öffentlichen Chaträ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), https://github.com/matrix-org/matrix-bifrost/graphs/code-frequency (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ügbaren 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

Umwandelung
Chatadressen (Chatstandard XMPP), SMS (Telefonnummern), E-Mail-Adressen sowie SIP-Adressen kann man sich hier im Matrixformat anzeigen lasen: https://cheogram.com/matrix (extern)

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-Verbindungen (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 (extern)

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 und Teamchatfunktionen genießen - und trotzdem wäre ein standardisierter Austausch von Nachrichten von/nach außen möglich.

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

Matrix Logo