Lesezeit ca. 11 Min.
arrow_back

Die rote Pille


Logo von IT Administrator
IT Administrator - epaper ⋅ Ausgabe 1/2023 vom 30.12.2022
Artikelbild für den Artikel "Die rote Pille" aus der Ausgabe 1/2023 von IT Administrator. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: IT Administrator, Ausgabe 1/2023

Im Filmklassiker "Matrix" steht der Protagonist Neo vor der Wahl: Soll er in der scheinbar sicheren, aber fremdkontrollierten Welt bleiben oder sich der harten Realität stellen? Bei Chatsystemen ist die Wahl natürlich nicht ganz so schwerwiegend, dennoch stehen Anwender oftmals vor der Entscheidung: Vertrauen sie Großkonzernen wie Meta (Facebook, WhatsApp), Alphabet (Google) oder dem undurchsichtigen Firmenkonstrukt Telegram ihre Chat- und Gruppenkommunikation an oder lieber nicht? Wer den Komfort einer modernen Chatapplikation mit Gruppen schätzt, seine Daten aber lieber selbst sichert, hat mit Matrix [1] eine ernstzunehmende Alternative zur Wahl. Allerdings erfordert deren Setup wiederum einen höheren Aufwand und natürlich einen eigenen Server.

Offenes Protokoll

Matrix selbst ist keine Software. Es handelt sich hierbei um ein quelloffenes, Ende-zu-Ende verschlüsseltes Protokoll für Chat- und ...". Darauf erstellt er seine eigenen Benutzer, deren Namen dem Schema "@name: ...

Weiterlesen
epaper-Einzelheft 10,99€
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von IT Administrator. Alle Rechte vorbehalten.
Lesen Sie jetzt diesen Artikel und viele weitere spannende Reportagen, Interviews, Hintergrundberichte, Kommentare und mehr aus über 1050 Magazinen und Zeitungen. Mit der Zeitschriften-Flatrate NEWS von United Kiosk können Sie nicht nur in den aktuellen Ausgaben, sondern auch in Sonderheften und im umfassenden Archiv der Titel stöbern und nach Ihren Themen und Interessensgebieten suchen. Neben der großen Auswahl und dem einfachen Zugriff auf das aktuelle Wissen der Welt profitieren Sie unter anderem von diesen fünf Vorteilen:

  • Schwerpunkt auf deutschsprachige Magazine
  • Papier sparen & Umwelt schonen
  • Nur bei uns: Leselisten (wie Playlists)
  • Zertifizierte Sicherheit
  • Freundlicher Service
Erfahren Sie hier mehr über United Kiosk NEWS.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 1/2023 von Im Grunde gut. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Im Grunde gut
Titelbild der Ausgabe 1/2023 von Clone-Phishing auf dem Vormarsch. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Clone-Phishing auf dem Vormarsch
Titelbild der Ausgabe 1/2023 von Alles an Board. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Alles an Board
Titelbild der Ausgabe 1/2023 von Erfolgreiches Schutzschild. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Erfolgreiches Schutzschild
Mehr Lesetipps
Blättern im Magazin
You have new mail
Vorheriger Artikel
You have new mail
Isoliert, aber nicht allein
Nächster Artikel
Isoliert, aber nicht allein
Mehr Lesetipps

Matrix selbst ist keine Software. Es handelt sich hierbei um ein quelloffenes, Ende-zu-Ende verschlüsseltes Protokoll für Chat- und Echtzeitkommunikation. Als offener Standard stellt es sicher, dass verschiedene Softwareimplementierungen wie "Element" (Client) oder "Synapse" (Server) zueinander kompatibel bleiben. Das Prinzip von Matrix ist dabei simpel: Der Anwender betreibt seinen Matrix-Server passend zu einer Internetdomäne wie "". Darauf erstellt er seine eigenen Benutzer, deren Namen dem Schema "@name:domain.com" folgen.

Bis hier hin wäre alles sehr einfach und nur ein weiterer geschlossener Chatdienst. Doch Matrix erlaubt, den Server im Internet zu publizieren (Federation). Das ermöglicht, dass sich Nutzer verschiedener Matrix-Server miteinander verbinden. Vereinfacht gesagt folgt Matrix damit dem Vorbild des SMTP-Mailservers. Der verteilt lokale Nachrichten innerhalb des geschlossenen Netzwerks und leitet externe Nachrichten zu den jeweiligen SMTP-Servern der anderen Domänen. Wie bei Maildiensten mischen sich hierbei selbstgehostete Lösungen samt eigener Server mit Cloudangeboten wie "". Allerdings bleibt Matrix-Usern der Spam erspart, mit dem Mailnutzer tagtäglich leben müssen. Denn anders als SMTP stellt das Matrix-Protokoll nicht ungefragt alle Nachrichten zu. Möchte ein Nutzer einer fremden Domain Kontakt via Chat aufnehmen, muss der Empfänger dem zustimmen.

Wer einen eigenen Matrix-Server einrichtet, steht dann natürlich vor dem Problem, dass viele seiner bestehenden Kontakte trotzdem auf WhatsApp, Facebook Messenger oder Telegram bleiben. Alternativ arbeiten sie mit geschlossenen Systemen wie Discord oder Slack. Dafür offeriert Matrix eine ganze Serie von Bridges. Die klinken sich für den jeweiligen User in die fremden Dienste ein und leiten Nachrichten zu Matrix weiter. Mit der korrekten Konfiguration muss ein Anwender dann nur noch einen einzigen Matrix-Chatclient verwenden, über den er sowohl mit anderen Matrix-Nutzern als auch allen anderen Chatplattformen über den einen Matrix-Server kommunizieren kann.

Nachfolgend zeigen wir, wie Sie einen eigenen Matrix-Server mit der Open-Source-Software "Synapse" aufsetzen, dazu passende Clients nutzen und eine Bridge für WhatsApp aufsetzen. Natürlich lässt sich Synapse in einer virtuellen Maschine mit Debian- oder Fedora-Linux betreiben. Wir setzen den Server containerisiert mit Podman (alternativ: Docker) auf, das funktioniert dann weitgehend unabhängig vom eigentlichen Server-OS.

Vorbereitungen

Bevor es an das eigentliche Setup des in Python geschriebenen Synapse-Servers für Matrix geht, müssen Sie ein paar Vorbereitungen treffen. Der Matrix-Service im Container verwendet das HTTP-Protokoll auf Port 8008 oder HTTPS auf Port 8448. Sie könnten nun Port 8448 freigeben, den Matrix-Traffic dorthin leiten und dem Synapse-Server selbst ein gültiges Zertifikat beispielsweise via Let's Encrypt geben. Das ist aber mehr Aufwand als nötig. In unserem Beispiel läuft der Synapse-Dienst auf einem Mietserver (Hetzner) mit einer einzigen IP-Adresse. Den Server nutzt auch eine ganze Reihe anderer Dienste. Den ankommenden Traffic verteilt daher ein Nginx-Reverse-Proxy an die verschiedenen Service-Container basierend auf dem Namen der Dienste. Pakete für "" gehen an einen anderen Container als Anfragen an "dienst5.domain.com". Zudem übernimmt der Nginx-Server die SSL-Terminierung für alle Dienste und verwaltet das Let's-Encrypt-Zertifikat der Domain. Zwischen Proxy und den eigentlichen Diensten genügt dann HTTP.

Für Synapse nutzen wir im Beispiel den DNS-Namen "" und den regulären HTTPS-Port 443. Je nachdem, wie Sie ihr Docker/Podman-Setup betreiben, leitet Nginx den Traffic auf eine interne Bridge-IP-Adresse oder gemappten Port weiter. Bei unserem Beispiel handelt es sich um eine "gewachsene" Infrastruktur, die nach und nach Dienste von traditionellen VMs in Container migriert. Daher laufen diese Container auf demselben Bridged Network wie die VMs und jeder Container verfügt über eine eigene interne IP-Adresse. Ein Grund dafür ist auch die Sicherheit. Der Zugang zu Diensten auf einem internen Netzwerk lässt sich besser über die Firewall kontrollieren und überwachen, als wenn Container sich direkt auf das extern zugängliche Interface per Port-Mapping binden.

Unsere Reverse-Proxy-Konfiguration für den Synapse-Server ("/etc/nginx/conf.d/ matrix.conf ") sieht daher in etwa so aus:

server { listen 443 ssl http2;

server_name ; ssl_certificate /etc/ letsencrypt/live/ domain.com/fullchain.pem; # managed by Certbot

ssl_certificate_key /etc/letsencrypt/ live/; # managed by Certbot

[...] (SSL- und LOG-Parameter)

location ~ ^(/_matrix|/

_synapse/client) { client_max_body_size 100M; proxy_pass ; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $host;

}

Damit gelangt nun sämtlicher HTTPS-Verkehr für "" an Port 8008 des Containers auf der internen Bridge-IP 192.168.122.26. Wenn Sie Container ohne lokale Bridge betreiben, lautet der Eintrag "proxy_pass http://127. 0.0.1: 8008;".

Nach Außen hin heißt Ihr Synapse-Server "", aber der eigentliche Dienst soll Namen wie "@user1:domain.com", und nicht "@user1:matrix.domain.com" verwenden. Sie müssen also im weiteren Verlauf ihren Synapse-Server mit der Konfiguration "domain.com" betreiben und gleichzeitig fremden Servern mitteilen, dass die Chatnachrichten für "domain.com" an den Server "https://matrix.domain.com:443" geleitet werden sollen. Für die Discovery nutzt das Matrix-Protokoll zwei Optionen. Ein Server, der den Kontakt zu einer anderen Domäne herstellen will, versucht den Zielserver zuerst über eine DNS-Abfrage ausfindig zu machen. Hier folgt Synapse dem Beispiel von SNMP, das den Mailserver einer Domäne über den DNS-Eintrag "MX" publiziert. Matrix fragt nach einem SRV-Eintrag namens "_matrix._tcp", also in unserem Beispiel nach "_matrix._tcp.domain.com". Die Antwort muss dann entsprechend "matrix.domain.com" und Port 443 lauten.

Allerdings können nicht alle Domain-Inhaber problemlos DNS-Einträge anlegen oder ändern. Schlägt also die DNS-Query nach dem SRV-Eintrag fehl, probiert das Matrix-Protokoll einen anderen Weg: Es startet eine Rest-API-Anfrage via HTTPS an den Domänennamen mit der URL "/.well-known/matrix/server"– in unserem Fall also an "". Darauf erwartet Matrix eine HTTP-200-Antwort im JSON-Format. Diese Antwort übergibt in unserem Beispiel ebenfalls der Nginx-Reverse-Proxy. Die Konfiguration hierfür steht in der Regel in der Basiskonfiguration des Nginx-Servers "/etc/nginx/nginx.conf ":

server { listen 443 ssl http2; server_name ; root /usr/share/nginx/html/blank;

[…] (SSL-Konfiguration)

location /.well-known/matrix/server { default_type application/json; return 200 '{"m.server": ""}';

}

}

Synapse konfigurieren

Um den Synapse-Server konfigurieren zu können, brauchen Sie erst einmal eine Konfigurationsdatei. Die erstellt das Tool beim ersten Start freundlicherweise selber. Legen Sie ein Verzeichnis auf dem Containerhost an, in dem Synapse seine Daten speichert. In unserem Setup ist das "/var/ pods/synapse". Dann starten Sie den Container wie folgt:

podman run -it --rm \ --name synapse \ --volume /var/pods/ synapse:/data:Z \ -e SYNAPSE_SERVER_NAME=

\ -e SYNAPSE_REPORT_STATS=yes \ docker.io/matrixdotorg/ synapse:latest generate

Sollten Sie Docker statt Podman verwenden, müssen Sie das Kommando als root via docker run ausführen. Das "Z" am Ende der Volume-Angabe brauchen Sie auf Systemen mit aktivem SELinux. Der Schalter "SYNAPSE_REPORT_STATS" erlaubt Synapse, anonyme Betriebsstatistiken an die Entwickler zu senden. Wenn Sie das nicht wünschen, geben Sie hier "no" an.

Am Ende des Kommandos erhalten Sie eine Datei namens "homeserver.yaml" sowie eine "log.config" und einen Signing-Key im Verzeichnis "/var/pods/synapse". In der YAML-Datei finden Sie die Basiskonfiguration des Diensts, der Datenbank und auch ein "registration_shared_secret". Das sollten Sie an einem sicheren Ort abspeichern – es wird zur Registrierung neuer Nutzer benötigt, sollte aber nach dem initialen Setup aus der "homeserver.yaml" verschwinden.

Als Datenbank nutzt Synapse in der Basiskonfiguration SQLite. Das genügt für kleine Testinstallationen. Setzen Sie einen Synapse-Server für dutzende Nutzer und Chaträume auf, sollten Sie auf jeden Fall statt SQLite einen PostgreSQL-Server verwenden. Die Synapse-Dokumentation beschreibt ausführlich, wie Sie eine PostgreSQL-Datenbank einrichten, das muss aber nicht zwingend sofort mit der ersten Testinstallation passieren. Die Dokumentation beschreibt ebenfalls, wie Sie eine bestehende SQLite-Datenbank nachträglich zu PostgreSQL übertragen und den Synapse-Server passend umstellen. In unserem Testsetup bleiben wir bei SQLite.

Mit der passenden Konfiguration können Sie nun ihren Synapse-Container starten. Je nach Netzwerkkonfiguration betreiben Sie ihn auf der Host-IP mit dem Parameter "-p 8008:8008", um den HTTP-Port auf verfügbar zu machen. Unser Setup nutzt Synapse auf der Bridge via -- net virt_net --ip 192.168.122.26 --mac-address 53:54:C0:A8:7A:1A und damit mit seiner eigenen IP-Adresse. Erstellen Sie anschließend eine "service"-Definition für den Synapse-Server, sodass Systemd den Pod beim Systemstart ausführen kann.

Benutzer anlegen

Neue Benutzer registrieren Sie auf der Kommandozeile des Hosts im laufenden Synapse-Container:

podman exec -it synapse register_new_matrix_user -c /data/homeserver.yaml <username>

Geben Sie ein Passwort an und statten Sie den initialen Nutzer mit Admin-Rechten aus. In einem größeren Setup werden Sie natürlich nicht alle Nutzer manuell per CLI generieren. Für Synapse gibt es verschiedene Authentisierungs-Plug-ins, sodass Sie Single Sign-on mit verschiedenen ID-Providern verwenden können. Alternativ fügen Sie in der "homeserver.yaml" die Ziele "enable_registration = true" ein. Das ist aber mit Vorsicht zu genießen, denn damit darf sich jeder Nutzer mit Zugang zum Server einen Account erstellen. Diese Funktion sollten Sie nur im lokalen Netzwerk aktivieren, solange der Server noch nicht über das Internet zu erreichen ist.

Matrix trennt den Client vom Server. Daher verfügt der Synapse-Server selbst auch über keine Web-UI. Die Administration erfolgt über die CLI, die Rest-API oder externe Tools mit Zugang zur Admin-Rest-API. Um den Dienst zu nutzen, gibt es eine ganze Reihe verschiedener Clients. Der wohl populärste ist "Element". Den können Nutzer als Webdienst im Browser unter "" nutzen oder von dieser Seite Client-Apps für Windows, Linux oder macOS herunterladen. In den App-Stores von Apple und Google gibt es Element zudem kostenfrei für iOS und Android.

Im Element-Client geben Sie statt "" die URL Ihres Matrix-Servers, im Beispiel also "https://matrix. domain. com ein. Melden Sie sich mit dem initialen Benutzer und dem vergebenen Passwort an. Gleich am Anfang wird Element Sie auffordern, ein "Secure Backup" einzurichten und einen Security-Key für die Ende-zu-Ende-Verschlüsselung zu erstellen. Generieren Sie diesen Schlüssel und speichern ihn an einem sicheren Ort. Sie können danach neue Clients nur noch mit ihrem Konto verbinden, wenn Sie entweder diesen Schlüssel angeben oder eine Zweifaktor-Authentifizierung über einen bereits registrierten Client nutzen. An dieser Stelle empfiehlt es sich, einen mobilen Client auf Ihrem Handy mit dem Konto zu verknüpfen. Weitere Clients können Sie dann via QR-Code freischalten, den Elements auf dem Handy scannt und verifiziert.

User Interface für Admins

Neben Elements als Messaging-Client-App gibt es auch ein paar Admin-UI-Projekte. Diese funktionieren aber nur mit Einschränkungen. Die oben aufgeführte Reverse-Proxy-Konfiguration gibt nur die Messaging-API ("/_matrix" und "/_synapse/client") zum Internet hin frei, nicht aber die Admin-API ("/_synapse/admin"), und das sollte auch so bleiben. In unserem Beispiel könnten Sie jedoch eine Admin-Web-UI direkt auf dem Hosting-Server in einem weiteren Container starten:

podman run \ --net virt_net \ --ip \ --mac-address 52:54:C0:A8:7A:1b \ docker.io/awesometechnologies/synapse-admin

Direkt auf dem Hosting-Server rufen Sie die URL "http:// " im Browser auf. Im folgenden Verbindungsdialog geben Sie den Admin-User an und als Matrix-URL passend zum Beispiel "http://192.168.122.26:8008", da Sie hierfür die interne Netzwerkverbindung zwischen den Containern nutzen und nicht über den Proxy gehen. Verfügt Ihr Hosting-Server über keine GUI, können Sie den Applikationsport der Web-UI 192.168.122.27:80 auf gewohnte Weise via SSH zu Ihrem Client tunneln und dann den Browser dort verwenden.

Federation prüfen

An diesem Punkt läuft Ihr Synapse-Server und die lokal erstellten Nutzer können darüber kommunizieren. Jetzt ist es an der Zeit, die Verbindung zu anderen Matrix-Domänen zu testen. Prüfen Sie zunächst, ob die Federation-Einstellungen Ihres Servers korrekt konfiguriert sind. Gehen Sie dazu einfach auf die Webseite: "" und geben Sie Ihren Domainnamen ein. Der Federation-Tester prüft beide Discovery-Methoden via DNS und Well-Known-Rest-API. Zudem verifiziert der Service ihre HTTPS-Zertifikate. Erscheint hier alles in grün, können andere Matrix-Nutzer Ihren Server erreichen und Ihre Nutzer dürfen im Gegenzug die Kommunikation mit anderen Domänen starten.

Matrix verwaltet alle Chats in "Räumen". Private Chats sind für Matrix nichts anderes als Gruppen mit nur zwei Mitgliedern.

Die Kommunikation auf dem lokalen Server sowie mit anderen Matrix-Installationen erfolgt mit Ende-zu-Ende-Verschlüsselung. Die Nachrichten selbst sichert das Synapse-Setup verschlüsselt in der angegebenen Datenbank.

Brücken bauen

Ein Matrix-Setup mit Synapse als Server und Element als universellem Client genügt für die sichere interne Kommunikation und Chats mit anderen Matrix-Nutzern. Allerdings chattet der Großteil der Nutzer auf anderen Plattformen, allen voran WhatsApp. Eine der großen Stärken von Matrix sind die Bridges. Mit diesen Plug-ins stellt Synapse über Bots Verbindungen zu anderen Diensten wie WhatsApp, Google Chat, Slack, Discord oder Telegram her. Mit einem umfassenden Synapse-Setup brauchen die Anwender also nur noch einen einzigen Matrix-Client, über den sie alle Chats, egal mit welcher Plattform, erledigen. Das Bridge-Setup ist für viele Plug-ins recht ähnlich. Wir stellen hier stellvertretend die wohl wichtigste Bridge vor: WhatsApp.

Die Bridge läuft als eigenständige Applikation und kann theoretisch auch auf einem ganz anderen Rechner als Synapse arbeiten. In unserem Setup läuft "Mautrix Whatsapp" als eigener Container mit einer eigenen IP-Adresse () auf demselben System wie Synapse. Das Plug-in braucht ein eigenes Verzeichnis und eine eigene Datenbank. Wie bei Synapse gilt auch hier: Für Testinstallationen genügt SQLite, größere Setups sollten PostgreSQL verwenden. Legen Sie das Verzeichnis "/var/pods/mautrix_whatsapp" an und starten Sie den Plug-in-Container einmalig:

podman run --rm \ --name mautrix_whatsapp \ --volume /var/pods/mautrix_whatsapp:/data:Z \ whatsapp:latest

Die Bridge stellt beim ersten Start fest, dass es keine Konfigurationsdatei gibt. Der Container legt daher im angegebenen Verzeichnis eine "config.yaml" mit Standard-Settings an und stoppt. Passen Sie die Datei für Ihre Installation an. Die wesentlichen Einträge für unser Setup sehen dabei so aus:

homeserver: address: domain: domain.com appservice: address: http://192.168.122.31:29318 hostname: 0.0.0.0 port: 29318 database: type: sqlite3 uri: whatsapp.db

Zudem müssen Sie die Einstellung "Permission" passend zu Ihrer Domäne konfigurieren, sodass nur die Nutzer Ihrer Domain die Bridge aktiv verwenden dürfen.

permissions: "*": relay "": user "@admin:domain.com": admin

Den Synapse-Server spricht das Plug-in direkt über die interne Adresse an und stellt im Gegenzug den eigenen Dienst auf der internen IP-Adresse des Containers zur Verfügung. Abweichend zur Dokumentation des Plug-ins enthält die Datenbank-URL bei SQLite nur den Dateinamen der Datenbank ohne Pfad und ohne "sqlite://" am Anfang. Beim nächsten Start des Containers geben Sie die IP-Informationen mit an: --net virt_net --ip 192.168.122.31 --mac-address 52:54:C0:A8:7A:1f. Auch hier gilt: Wenn Sie Ihre Container ohne Bridge-Network betreiben, stellen Sie alle Adressen auf und geben statt der Netzwerkinformationen nur den Port "-p 29318: 29318" mit an.

Beim zweiten Aufruf erstellt das Plug-in die Datenbank und prüft die Verbindung zum Synapse-Server. Passt das Setup, generiert "mautrix-whatsapp" eine "registration.yaml" und stoppt den Container. Diese Registration enthält vereinfacht gesagt die Zugangsdaten des Plug-ins zum Synapse-Server. Erstellen Sie eine Kopie der "registration.yaml"-Datei im Verzeichnis des Synapse-Servers, am besten gleich mit dem Plug-in-Namen, also:

cp /var/pods/mautrix_whatsapp/registration.yaml /var/pods/synapse/registration_whatsapp.yaml

Link-Codes

[1] Matrix n1z31

Passen Sie danach die Konfiguration des Synapse-Servers in dessen /var/pods/synapse/homeserver.yaml an, so dass folgende Zeile enthalten ist:

app_service_config_files: - /data/registration_whatsapp.yaml

und starten den Synapse-Container neu. Für jedes weitere Bridge-Plug-in werden Sie jeweils eine eigene Registration-Datei erstellen und auf die gleiche Art und Weise dem Synapse-Dienst hinzufügen. Starten Sie jetzt den "mautrix-whatsapp"-Container erneut (ohne "--rm"), registriert er sich am Synapse-Dienst und bleibt von nun an als Bot aktiv. Andere Bridges wie etwa für Facebook Messenger oder Slack funktionieren bis dahin nahezu identisch. Die Art und Weise der Authentisierung mit dem jeweiligen Dienst unterscheidet sich allerdings.

Möchten Sie die WhatsApp-Brücke verwenden, brauchen Sie zwei Dinge: Einen Matrix-Client wie Element (bevorzugt auf dem Desktop) und Ihr Handy mit dem WhatsApp-Client. In Matrix laden Sie den WhatsApp-Bot "@whatsappbot:domain. com" zum Chat ein. Im privaten Chat-Room geben Sie dem Bot Kommandos, allen voran "login". Als Antwort sendet der Bot jetzt einen QR-Code. In der Handy-App von WhatsApp gehen Sie in das Menü: "Verknüpfte Geräte" und wählen dort: "Gerät hinzufügen". Scannen Sie den QR-Code, um dem WhatsApp-Bot den Zugriff auf die Chats zu genehmigen. Geben Sie dann dem Bot erst einmal etwas Zeit, um Ihre Whats-App-Konfiguration einzulesen. Alle Funktionen listet der Bot übrigens mit dem Kommando "help" auf.

Der Bot gleicht nicht all Ihre WhatsApp-Kommunikation direkt mit Matrix ab. Vielmehr wählen Sie individuell aus, welche privaten WhatsApp-Chats und -Räume Sie synchronisieren möchten. Um eine Gruppe in Matrix zu übernehmen, listen Sie zuerst via Bot-Kommando die verfügbaren Gruppen auf: list groups. Der Bot liefert die Liste und zu jeder Gruppe eine eindeutige ID. Geben Sie nun als Befehl open <group-ID> ein, erstellt der Bot einen Matrix-Chat-Raum passend zur Gruppe. Alles, was Sie dort via Matrix-Client posten, erscheint in WhatsApp genau so, als würden Sie es direkt in den Whats-App-Client eintippen. Private Chats legen Sie entsprechend mit dem Bot-Kommando: pm <Telefonnummer> an. Jetzt können Sie innerhalb des Element-Clients mit Matrix- und WhatsApp-Usern kommunizieren, wobei die WhatsApp-Kommunikation dann natürlich ohne die Ende-zu-Ende-Verschlüsselung arbeitet.

Fazit

Das Basissetup einer Chatinfrastruktur mit Synapse braucht etwas Planung und Zeit. Im Gegenzug erhält der Anwender eine sichere Kommunikationsplattform abseits der etablierten Drittanbieter. Dank der vielen Bridges ermöglicht Matrix nichtsdestotrotz auch die Kommunikation mit den populären Chatnetzwerken.

(dr)