Verschiedene LUKis testen gerade verschiedene Messenger, die angetreten sind, um die zentrale Marktherrschaft eines bestimmten zentralisierten, closed-sourced Messengers in Frage zu stellen.
Hier kommt meine Einschätzung des Matrix Protokolls bzw. seiner aktuellen Implementierung in Form von riot.im:
Matrix/riot.im:
ist angetreten, das XMPP-Protokoll zu beerben und dessen Schwächen zu beheben
will dezentral und mit dem Web und mobilen Geräten gut nutzbar sein
bietet vielfältige Funktionen, inkl. Telefonie und AV-Konferenz
bietet mit riot.im viele funktionsfähige Implementierungen auf unterschiedlichen Plattformen
Klingt also spannend.
Probleme:
Ein dezentraler Server ist schnell aufgesetzt (gut!), aber die Entwicklerfirma hinter Matrix/Riot.im betreibt einen zentralisierten Identitätsserver. Ohne diesen Identitätsserver sind die Anwendungen imho nur einem eingeschränkten Nutzerkreis zugänglich (so wie
IRC/XMPP), weil man die Nutzerkennung auf drittem Wege austauschen muss.
Die Verschlüsselung in der Web-App wird als „beta“ eingestuft. Das halte ich für eine grobe Beschönigung. Ein per HTTP/Server ausgelieferter kryptographischer Javascript-Code kann nicht sicher sein, weil es derzeit keine Möglichkeit gibt, die Code-Integrität von Javascript-Code browserseitig zu überprüfen (korrigiert mich, wenn ich falsch liege). Das bedeutet, dass man jede verschlüsselte Nachricht, die von der WebApp versendet wird, prinzipiell als unsicher einstufen muss, weil der Server jederzeit fehlerhaften kryptographischen Code ausliefern kann (beabsichtigt oder unbeabsichtigt durch Code Intrusion).
Anmerkung: Die Verschlüsselung bezieht sich auf die Verschlüsselung von Räumen durch eine End-zu-End Verschlüsselung. Solange man den Server selber kontrolliert, ist eine Verschlüsselung nicht zwingend erforderlich. Die Transportverschlüsselung selber geschieht immer über SSL/HTTPS - ist also von diesem Problem nicht betroffen. Im Wesentlich kein großer Unterschied zu Mattermost, Rocketchat, Slack und Co. Für den Anwender wäre hier wichtig darauf hinzuweisen, dass bei Nutzung der Weboberfläche keine Ende-zu-Ende-Verschlüsselung besteht.
Vorteile:
Einfach aufzusetzender Server
Push-Nachrichten funktionieren ohne dass die App im Hintergrund laufen muss (dafür aber Sammlung von Meta-Daten beim Push-Server).
Funktionierende Referenzclienten für iOS, MacOS, Linux, Windows, Android. Ein Sailfish/Mer Client ist in Arbeit
Integrierte VoIP und Videotelefonielösung
Offenes Design - das „bridgen“ zu anderen Platformen ist nicht nur möglich, sondern vorgesehen. Es existieren Brücken zu
IRC, XMPP-MUCs, Slack, Telegram uvm.. Das heißt man kann an Matrixdiskussionen auch mit einem völlig anonymen, über TOR getunnelten,
IRC Clienten teilnehmen.
Der Identitässever kann benutzt werden. Damit verläuft das Suchen nach Kontakten analog zu den bekannten Mechanismen bei WhatsApp und Co. Ergänzung: Er sollte aber nicht benutzt werden. Hier ist der kritische Punkt.
Meine Bewertung; TL;DR:
Spannende Open-Source-Idee, die viele technische Probleme anderer Messenger löst. Mit dem zentralen Identitätsserver in den UK und der WebApp kann „out of the box“ aber nicht sicher und datenschutzkonform gearbeitet werden.
Für seriöse kirchliche (seelsorgerliche oder amtliche) oder betriebliche Kommunikation ist das Produkt bei dem aktuellen Stand (Dez. 2017) daher nicht verwendbar.
Das könnte geändert werden: Man weist bei der WebApp deutlich auf den fehlende Ende-zu-Ende-Verschlüsselung hin (und deaktiviert die existierende Funktion), betreibt einen eigenen, in Deutschland lokalisierten Identitätsserver und Push-Server und liefert eine App aus, die nur diese Server nutzt. Das wäre aber relativ viel Arbeit. Aber vielleicht lohnende?