1. Die Idee hinter diesem Beitrag
Die Idee zum vorliegenden Beitrag entstand während eines E-Mail-Wechsels mit Mike Kuketz auf meine Anfrage hin, warum der auf dem freien, föderalen Protokoll Matrix beruhende Messenger Riot, nicht Teil der Messenger-Empfehlungsstrecke ist. Meiner Auffassung nach stellt Matrix über Riot nämlich die ideale Ergänzung zu Mikes aktueller Klassifizierung von »Signal« für »Einsteiger / Wechselwillige« und »Conversations | ChatSecure – Android & iOS« (also XMPP-basierte Messenger) für »Fortgeschrittene« dar.
Gastbeitrag
Ein Gastbeitrag von Roland Hummel – Lizenz des Artikels: CC-BY-SA.2. Ausgangsthese
Matrix ist aktuell eine ideale Umsetzung für das, was XMPP immer sein wollte (aber wenn überhaupt nur unter großem administrativen Aufwand ist): Ein freies, föderales Messenger-Protokoll, mit dem auch interessierte Hobby-Admins einen »State of the Art«-Messenger auf dem eigenen Server hosten können – allerdings mit im Vergleich zu XMPP sehr viel geringerem Konfigurationsaufwand, um eine von aktuellen Mainstream-Messengern gewohnte Usability zu erhalten bzw. diese sogar zu übertreffen, bedenkt man aktuellste Konzepte, die bspw. Slack sehr erfolgreich gemacht haben.
Mike sah das zum besagten Zeitpunkt anders, war aber so freundlich und offen, mir die Möglichkeit für einen Gastbeitrag einzuräumen, meine Sichtweise auf die Thematik darzustellen und sich ggf. von Matrix überzeugen zu lassen. Da meiner Meinung nach jede Diskussion um Datenschutz zuallererst eine sein sollte, die aus einem zivilgesellschaftlichen Autonomiebedürfnis heraus begonnen wird (und deswegen auch eine juristische und technische ist, nicht andersherum), möchte ich mein Votum für Matrix/Riot nachfolgend aus einer zivilgesellschaftlichen Perspektive untermauern, aber entsprechend auch auf eines der Haupt-Themen dieses Blogs eingehen: Den Datenschutz bzw. das Recht auf informationelle Selbstbestimmung.
3. Zu meinem Hintergrund
Ich bin IT-interessierter Student eines alles andere als technischen Studienfachs an der Humboldt-Universität zu Berlin. Im Zuge der globalen Überwachungs- und Spionageaffäre, ausgelöst durch die Enthüllungen von Edward Snowden, habe ich versucht, mit einer studentischen Initiative namens »Jahr 1 nach Snowden« das Problem von Überwachung in Podiumsdiskussionen interdisziplinär zu untersuchen (philosophisch, technisch, gesellschaftspolitisch). Dabei wurden auch in studentischen Seminaren versucht, sich den theoretischen Problemen praktisch zu nähern. Im Zuge der Vorbereitung dieser Seminare vollzog sich für mich konsequenterweise der vollständige Wechsel weg von Windows hin zu GNU/Linux als Betriebssystem, gefolgt von einer Begeisterung für die Möglichkeiten, die Freie Software an Selbstbestimmung (»sapere aude!«) mit sich bringt (zumindest nachdem ich verstanden hatte, wie man sich auf einer Kommandozeile bewegt). »Geistiges Kind« sowohl der universitären Snowden-Initiative als auch meiner privaten Begeisterung für Freie Software ist eine weitere stud. Initiative mit dem Titel gnuHU-linux, mit der ich erreichen möchte, dass alle von Student*innen nutzbaren IT-Infrastrukturen der Humboldt-Universität nach dem Kriterium zivilgesellschaftlicher Kontroll- und Gestaltungsmöglichkeit betrieben werden (oder weniger sperrig formuliert: GNU/Linux als feste Wahl-Alternative zu den Windows- und macOS-Systemen verfügbar ist).
Letztgenannter Punkt ist deswegen im Zusammenhang dieses Artikels wichtig, weil unter diesem Anspruch – den digitalen Raum zivilgesellschaftlich (mit)gestalt- und (mit)kontrollierbar zu nutzen – ein kleiner Kreis aus Freund*innen und ich mehrere Monate auf der Suche nach dem (nicht vorhandenen) idealen Messenger waren. Mikes Artikel Conversations: Sicherer Android Messenger war diesbezüglich ein Augenöffner für uns »Feierabend-Admins«, die endlich das »digitale Disneyland« vermeintlich kostenloser IT-Services verlassen wollten. Ergebnis dieser Suche war am Ende »Matrix«.
4. Föderale Messenger
Der Kuketz-Blog ist spendenfinanziert!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
4.1 XMPP-Server auf Basis von Prosody
Die meiste Zeit unserer Messenger-Tests nahm ein XMPP-Server auf Basis von Prosody ein, der unseren damaligen Recherchen nach als einstiegsfreundlicher XMPP-Serverdienst galt. Obwohl die Ersteinrichtung tatsächlich denkbar simpel verlief und ich auch das nächtelange Einlesen in entsprechende XEP-Erweiterungen als durchaus interessant empfand, zeigten sich im produktiven Betrieb Probleme, die kein Vertrauen in das System aufkommen ließen:
- Verlorene Nachrichten: Nachrichten gingen nicht reproduzierbar verloren, wurden als »nicht zugestellt« markiert (wurden aber dennoch übertragen) oder andersherum: Wurden laut Client übertragen, tatsächlich aber nie zugestellt. Dies fiel uns meist nur indirekt dadurch auf, dass User in MUCs auf etwas antworteten, was aus Sicht einzelner User zusammenhanglos war.
- Unzuverlässiger Sync: Weniger, aber auch nervig, war der unzuverlässige Sync von Nachrichten über mehrere Clients (Mobil / Desktop).
- Katastrophale Client-Situation: Der endgültige Grund zur Neuorientierung hinsichtlich eines föderalen Messenger-Systems war jedoch die damals katastrophale Client-Situation unter iOS: Da der »harte Kern« unserer Tester*innen selbst nur unter Android unterwegs war, kannten wir als iOS-Clients nur Astrachat und ChatSecure, wobei nur letztere Freie Software ist und wir ihn deswegen den ersten »Wechselwilligen« iOS-Usern empfahlen. Hier funktionierte der Nachrichtenaustausch vor allem in MUCs jedoch überhaupt nicht und OMEMO-Initialisierungen waren reine Glückssache.
Der Betrieb von Prosody (und insbesondere die Probleme unter iOS) bedienten leider sämtliche Vorurteile unserer Tester*innen:
Ich find‘ ja euer Anliegen richtig, aber euer Kram funktioniert halt nicht so richtig…
4.2 Matrix-Server auf Basis von »Synapse«
Noch etwas unentschlossen, wie es nun weitergehen sollte, versuchte ich im November 2017, einen Matrix-Server auf Basis von Synapse aufzusetzen. Mit Matrix steht ein freies, föderales Messenger-Protokoll zur Verfügung, dass mit Riot einen Referenz-Client für alle gängigen Plattformen (sogar unter F-Droid) mitbringt.
Die Installation unter Debian GNU/Linux war zunächst (unter #root) mit…
apt install build-essential python2.7-dev libffi-dev python-pip python-setuptools sqlite3 libssl-dev python-virtualenv libjpeg-dev libxslt1-dev pip install --upgrade pip pip install --upgrade ndg-httpsclient pip install --upgrade virtualenv useradd -m -d /opt/synapse -s /bin/false synapse su - synapse -s /bin/bash virtualenv -p python2.7 ~/.synapse source ~/.synapse/bin/activate pip install --upgrade pip pip install --upgrade setuptools pip install https://github.com/matrix-org/synapse/tarball/master cd ~/.synapse python -m synapse.app.homeserver --server-name my.domain.name --config-path homeserver.yaml --generate-config --report-stats=no
…komplexer als ein apt install prosody
Der »Wow-Effekt« ergab sich allerdings aus dem Umstand, dass danach ohne Nachjustieren ein Messenger-Dienst zur Verfügung stand, der »out of the box« zuverlässig alle Nachrichten übertrug, alle Nachrichten sauber über verschiedene Clients synchronisierte, dies auf allen gängigen Plattformen mit gleicher Oberfläche ermöglichte (für den Support ungemein von Vorteil) und sogar Kollaborations-Features ähnlich des Dienstes Slack mit sich brachte. Randnotiz: Nach meiner Auffassung ist Slack nach WhatsApp die nächste »Datenschutz-Epidemie«, die um sich greifen wird.
Nachdem ich nun Kritik an XMPP geäußert habe, ahne ich den ersten (berechtigten) Einwand.
5. »Das Problem ist nicht XMPP, sondern dein Server-Setup!«
Diese Kritik ist durchaus berechtigt, allerdings möchte ich an dieser Stelle an meine Ausgangsthese erinnern:
Ich sehe aktuell nur in Matrix die Möglichkeit, ein föderales Messenger-System (inkl. funktionierender Clients für alle Plattformen) auch als interessierter Hobby-Admin betreiben zu können, der kein »IT-Studium« hinter sich hat und ebenso nicht die Zeit für mehr oder weniger gut dokumentierte XEP-Konfigurationen aufbringen kann, die für XMPP nötig sind, wenn man eine halbwegs akzeptable Usability erreichen möchte.
Ich sage das nicht, weil ich frustriert auf einem alt-ehrwürdigen Standard wie XMPP »rumbashen« will, nur weil ich an der praktischen Umsetzung gescheitert bin, sondern weil ich es wirklich schade finde, dass XMPP trotz seiner über Jahre vorhandenen Führungsposition im Bereich dezentraler Messenger-Systeme, es nicht geschafft hat, ein System wie Matrix bereitzustellen. Ein System, mit dem auch Leute mit begrenzten zeitlichen Möglichkeiten und begrenztem IT-Wissen in der Lage sind, ein breites föderales Netzwerk bereitzustellen, das dann auch wirklich zuverlässig funktioniert. XMPP bedient in der aktuellen Form für mich das Vorurteil, dass »dieser dezentrale Open-Source Kram« nur etwas für eine bestimmte »IT-Elite« ist, womit das (für mich) eigentliche Ziel verfehlt wird, eine digital mündige Zivilgesellschaft mit aufzubauen.
Da ich immer wieder von zivilgesellschaftlicher Kontrolle als Kriterium bei der Messenger-Wahl gesprochen habe, möchte ich nachfolgend meine Kriterien, die zu Matrix geführt haben (XMPP aber nicht ausschließen), zusammenfassen:
6. Bewertungskriterien für Messenger unter zivilgesellschaftlicher Kontrolle
- Zivilgesellschaftliche Kontrollmöglichkeit durch Freie Software für Clients und Server.
- Zivilgesellschaftliche Autonomie durch die Möglichkeit eines dezentralen / föderalen Server-Betriebs.
- Für »Normal-User« benutzbare Clients für Windows / GNU-Linux / macOS / Android / iOS.
- Unabhängigkeit von Mobilfunkverträgen. Also: Eigenständige Account-Daten ohne Bindung des Accounts an Telefonnummer oder E-Mail. Das bedeutet auch: Nutzbarkeit des Systems muss auch ohne Smartphone möglich sein.
- Verlässlicher Nachrichtentransfer und zuverlässige Fehlermeldung bei Unzustellbarkeit von Nachrichten, Bildern und Videos.
- Möglichkeit zur Ende-zu-Ende-Verschlüsslung für Einzel- und Gruppenchats.
Nochmal zur Klarstellung: Ein zuverlässiger Nachrichtenaustausch ist ganz sicher auch mit XMPP möglich, wenn man die Zeit (und die Kenntnisse) hat, sich mit Compliance-Tests und den entsprechenden XEP-Erweiterungen zu befassen. Für all diejenigen, denen es wie mir geht (»von Beruf kein Vollzeit-Admin«), bietet Matrix einen interessanten Mittelweg, zumal Matrix von Anfang darauf ausgelegt wurde, in andere offene Netzwerke Brücken zu bauen.
Für Familie und Freund*innen, die meinen Matrix-Server nutzen, habe ich folgende Übersicht zusammengestellt, die in diesem Zusammenhang kurz und knapp beschreibt, was wir an Messenger-Systemen getestet hatten und warum die Wahl letztendlich auf Matrix fiel:
Warum Matrix und nicht…
- Briar: Frei, dezentral (peer-to-peer), ausschließlich Textnachrichten (keine Bilder), ausschließlich Android.
- Delta Chat: Frei, dezentral, funktional limitiert (nutzt E-Mail), ausschließlich Android.
- Telegram: Serverseitig proprietär, nicht dezentral.
- Threema: Client- und serverseitig proprietär, nicht dezentral.
- KakaoTalk: Client- und serverseitig proprietär, nicht dezentral.
- Jami: Frei, dezentral (peer-to-peer), keine Gruppen-Chats.
- Signal: Frei, aber nicht dezentral.
- Silence: Frei, dezentral, nutzt SMS/MMS-Dienst (Telefonnummernbindung).
- TOX: Frei, dezentral (peer-to-peer), keine Gruppen-Chats unter Android.
- WhatsApp: Client- und serverseitig proprietär, nicht dezentral.
- XMPP: Lange unser Favorit, frei, dezentral, leider große Probleme unter iOS / Apple in Gruppenchats, auch unter anderen Clients nicht reproduzierbarer Nachrichtenverlust festgestellt.
Hinweis
Alle »Bewertungen« beziehen sich auf einen Testzeitraum von Okt. 2016 bis Nov. 20177. Was das Matrix-Projekt in Bezug auf Synapse und Riot besser machen könnte
Die folgenden Punkte werden, speziell im Kontext des Kuketz-Blogs, mindestens Bauchschmerzen bereiten. Ich halte sie – im Rahmen meiner Ausgangsthese, ein funktionierendes, freies, föderales Messenger-System serverseitig auch für IT-Laien zu ermöglichen – für vertretbar, weil die Alternative (XMPP auf Basis von Prosody) aus oben genannten Gründen diesem (und nur diesem!) Anspruch an eine überschaubare Administrations-Komplexität für mich nicht gerecht wurde.
7.1 Identitätsserver
Der Client Riot nutzt einen sogenannten »Identitätsserver«, damit sich User (mit einem mittlerweile leider etablierten Komfortanspruch) auch ohne die Weitergabe der sog. Matrix-ID (@user:exmaple.org) gegenseitig hinzufügen können (also bspw. über Telefonnummer oder E-Mail-Adresse). Leider sind die Identitätsserver aktuell zentralisiert und speichern alle Adressdaten, die man ggf. zusätzlich in seinem Profil angegeben hat (bspw. auch die E-Mail-Adresse, wenn man diese für die Passwort-Reset-Funktion angegeben hat). Diese zentralisierten Identitätsserver sind auch für die Matrix-Entwickler ein »Desaster«, und daher eine temporäre Kompromisslösung, die unter Riot (Opt-Out) deaktiviert werden können:
Über den Punkt »Custom server« sollte man den Identitätsserver unter Riot daher entfernen. Für den zuverlässigen Betrieb sind Identitätsserver nicht notwendig!
7.2 Sammeln anonymisierter Analysedaten in Riot
Die Sammlung »anonymisierter Analysedaten« vollständig zu deaktivieren geht meines Wissens nach nur über den Desktop-Client bzw. die WebApp. Unter der Android-App konnte ich die Funktion nicht finden (korrigiert mich gerne), die Einstellung sollte aber über die Geräte gesynct werden (dafür spricht, dass alle anderen Einstellungen des jeweiligen Accounts immer auf allen Geräten synchron gehalten werden).
Die Übermittlung von Analysedaten lässt sich in Riot zumindest verweigern: »Einstellungen -> ANONYMISIERTE ANALYSEDATEN -> Zustimmung zur Übermittlung von anonymisierten Analysedaten verweigern«.
7.3 Serverseite Datenschutzoptimierungen
7.3.1 Statusinformationen
Unter dem Punkt »# Enable collection and rendering of performance metrics« bietet die homeserver.yaml-Konfirguationsdatei von Synapse zwei Einstellungsmöglichkeiten, die bei hohem Datenschutzbewusstsein auf False gesetzt werden sollten (in Bezug auf report_stats kann man dies gleich bei der Installation angeben, wie in meinem Beispiel oben):
enable_metrics: False report_stats: False
- enable_metrics: Wird bereits mit der Überschrift »Enable collection and rendering of performance metrics« erklärt.
- report_stats: Übersendet laut Release-Notes folgende Daten:
hostname, synapse version & uptime, total_users, total_nonbridged users, total_room_count, daily_active_users, daily_active_rooms, daily_messages and daily_sent_messages.
Die Einstellung auf »True« zu belassen wird mit folgender Aussage erbeten:
[…] the report-stats option is really really important for the ongoing health of the Matrix ecosystem: when raising funding to continue working on Matrix we have to be able to demonstrate how the ecosystem is growing and why it’s a good idea to support us to work on it.
Ich meine allerdings, dass durchaus auch anders für Matrix geworben werden kann, als mit statistischen Daten (beispielsweise durch diesen Gastbeitrag) und durch feste monatliche Spenden-Beträge. Dadurch wäre sicherlich ein besserer Support gewährleistet, als durch die Übermittlung von »anonymisierten« User-Daten. Wenn euch Matrix also gefällt, dann solltet ihr einen Dauerauftrag einrichten und report_stats auf »False« setzen.
7.3.2 Push-Notifications durch Google und Apple-Server
Ganz besondere Bauchschmerzen bereitet der letzte Punkt der homeserver.yaml-Konfirguationsdatei:
# Control how push messages are sent to google/apple to notifications. # Normally every message said in a room with one or more people using # mobile devices will be posted to a push server hosted by matrix.org # which is registered with google and apple in order to allow push # notifications to be sent to these mobile devices. # # Setting redact_content to true will make the push messages contain no # message content which will provide increased privacy. This is a # temporary solution pending improvements to Android and iPhone apps # to get content from the app rather than the notification. # # For modern android devices the notification content will still appear # because it is loaded by the app. iPhone, however will send a # notification saying only that a message arrived and who it came from. # push: redact_content: false
Warum hier nicht gleich
redact_content: true
gesetzt wurde, ist der letzte störende Punkt in der Reihe von Einstellungen, die aus Datenschutzperspektive unschön als Opt-Out geregelt sind. Die Opt-Out-Regelung betrachte ich allerdings wie gesagt als akzeptabel, weil ich dafür eine freien, föderalen Messenger bekomme, dessen Server-Implementierung sich auch für Laien an einem Nachmittag einrichten lässt, sowie plattformübergreifend für Laien nutzbare Referenz-Clients bereitstellt.
Dass überhaupt Google- und Apple-Dienste für die Push-Funktionalität genutzt werden, ist natürlich auch ein Problem. Diejenigen, die wirklich Wert auf Datenschutz legen, werden jedoch sehr wahrscheinlich ein GAPPS-freies Android nutzen, auf dem laut Matrix-FAQ Google Cloud Messaging nicht genutzt werden kann, woraus ich schließe, dass unter F-Droid die Push-Server nicht genutzt werden:
The F-Droid release of Riot does not use Google Cloud Messaging. This allows users that do not have or want Google Services installed to use Riot.
Alle anderen, die auf Standard-Android oder iOS unterwegs sind, kommen so zumindest in den Vorzug eines föderalen Systems mit modernen Kollaborations-Features (was im Hinblick auf das bereits erwähnte »Slack-Problem« den pädagogischen Mehrwert mit sich bringt, zu zeigen, dass man kein Slack nutzen muss, um zu »slacken«).
Danke für den Hinweis von Norbert H.:
Seit Mitte November ist im Riot-Client für iOS PushKit/CallKit implementiert. D.h. Push-Nachrichten müssen nun nicht mehr mit den eigentlichen Nachrichteninhalten (message content) verschickt werden, um als Benachrichtigung direkt lesbar zu sein (z.B. im Sperrbildschirm, Mitteilungszentrale, etc.). Der iOS-Client holt bzw. synchronisiert nun auch – genau wie der Android-Client – die Nachrichteninhalte direkt vom jeweiligen Matrix-Server des Benutzers (home server) und es müssen keine sensiblen Inhalte mehr an Apple oder Google übertragen werden. Man kann daher die Option »redact_content: true« immer setzen und trotzdem Benachrichtigungen samt der realen Nachrichteninhalte unter iOS erhalten (Anmerkung: Nur wenn im iOS-Client die Option »Zeige entschlüsselten Inhalt« aktiviert ist). Zudem wurde ein sogenannter »event_id_only« Push-Modus eingeführt, den alle neueren Riot-Clients nutzen und wo nur noch »event ID« sowie »room ID« in der Push-Nachricht (an bzw. von Apple/Google) enthalten sind. D.h. auch wenn die Option »redact_content: false« gesetzt ist, werden damit keine Nachrichteninhalte mehr an Dritte übertragen.
Die Option »redact_content« wurde zwischenzeitlich in »include_content« umbenannt und muss nun für den gleichen Effekt wie vorher (d.h. für grantiert entfernte Nachrichteninhalte) auf »include_content: false« stehen.
8. Fazit
Um den Einwand vorwegzunehmen, dass man, »wenn man keine Ahnung hat«, doch besser gleich Signal nehmen sollte: Bei allem Respekt für Moxie Marlinspikes Leistungen teile ich seine Ansicht…
One of the controversial things we did with Signal early on was to build it as an unfederated service. Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all.
…explizit nicht und halte sie insbesondere aus pädagogischer Sicht für zivilgesellschaftlich fatal. Erstens beweist das Matrix-Projekt mit Riot, dass »wettbewerbsfähige föderale Messenger« sehr wohl möglich sind und zweitens in der Messenger-Frage zivilgesellschaftlich nur dann langfristig wirkliche Fortschritte erzielt werden können, wenn die Zivilgesellschaft bewusst wieder Standards einfordert, die mit dem E-Mail-Protokoll einmal so selbstverständlich geworden waren, dass sie offensichtlich vergessen wurden: Offenheit und Föderalität.
Zur Erinnerung: Beides gibt uns die Möglichkeit, Kommunikationsnetzwerke zu betreiben, ohne von zentralen Providern abhängig zu sein und die Provider, wie (intuitiv) von E-Mail bekannt, beliebig austauschbar sind (oder wie es bereits die Überschrift eines in diesem Zusammenhang interessanten Artikels andeutet: »Why Privacy is more than Crypto«).
Unter den genannten Argumenten denke ich, dass Matrix in seiner Balance aus einfacher Administrierbarkeit und plattformübergreifender Nutzbarkeit, bei gleichzeitig hoher zivilgesellschaftlicher Gestalt- und Kontrollierbarkeit, einen Platz zwischen Signal und XMPP gebührt.
Für alle, die nun neugierig geworden sind, einige Hinweise zum Abschluss:
- Einen unverbindlichen Eindruck von Matrix könnt ihr euch verschaffen, wenn ihr euch bspw. im »Matrix-HQ« genannten Developer-Chat als Gast einloggt: https://riot.im/ -> Launch now on your Browser -> Login -> Login as guest -> Matrix HQ (kurz warten) -> Click here to join the discussion -> Username vergeben -> Continue (zum Ausloggen: unten links Settings-Button -> Sign out).
- Die oben genannten Installationsschritte sind nur ein Beispiel, ggf. solltet ihr bitte die offizielle Anleitung nutzen. Für den Audio/Video-Chat in Riot muss serverseitig noch ein TURN-Server installiert werden. Des Weiteren empfiehlt sich im produktiven Einsatz eine »ordentliche« Datenbank mit PostgreSQL – genaue Installationsschritte kann ich als Beispiel bei Bedarf nachreichen, bitte ggf. per Kommentar melden.
- Weitere Matrix-Clients neben Riot listet matrix.org auf.
- Eine Liste öffentlicher Matrix-Server findet ihr unter hello-matrix.net. Es wäre sinnvoll, wenn auch die, die keinen eigenen Matrix-Server betreiben wollen, sich im Sinne der Föderalität nicht alle auf matrix.org versammeln.
Update
20.03:2018: Nachtrag ergänzt.9. Nachtrag
Mike hatte mich um einige Nachträge gebeten, denen ich hiermit nachkommen möchte. Bei der Gelegenheit werde ich auch versuchen auf Fragen einzugehen, die sich durch die Kommentare ergaben. Danke an dieser Stelle für alle bisherigen Kommentare. Insgesamt freue ich mich sehr über den bisherigen Austausch und hoffe, dass es trotz der Debatte, die ab und an die Tendenz hat, einen »Glaubenskrieg« zu entfachen, bei einer beidseitig informativen Diskussion bleibt, die am Ende dem gemeinsamen Ziel nützt, offene, föderale Netzwerke zu stärken.
Ebenso möchte ich an dieser Stelle meinen (verspäteten) Dank an die User der LUKi-Mailingliste aussprechen (besonders an J. Brakensiek und Ph. Ruess), da viele Punkte, die Teil dieses Artikels sind, zuvor in entsprechenden Messenger-Debatten auf der LUKi-Mailingliste hilfreich problematisiert wurden.
9.1 »Ist die Ende-zu-Ende Verschlüsselung standardmäßig aktiv?«
Nein, die Matrix-Ende-zu-Ende-Verschlüsselung muss aktuell erst aktiviert werden. Desweiteren ist sie aktuell noch als beta gekennzeichnet und basiert auf Olm bzw. Megolm – meines Wissens nach Implementierungen des Double Ratchet-Verfahrens, das auch Grundlage der bspw. von Conversations bekannten OMEMO-Verschlüsselung ist.
Der praktische Einsatz gestaltet sich so, dass der Admin eines Matrix-Chat-Raumes die Verschlüsselung aktiviert. Randbemerkung: In der Philosophie von Matrix ist grundsätzlich jeder Chat ein Raum, auch wenn 2er-Chats, warum auch immer, nicht so gekennzeichnet werden. Für einen Chat mit egal wievielen Usern (auch in Chats für mich allein, um mir bspw. selbst Notizen über mehrere Clients zu senden) wird also ein Raum erstellt, der entsprechend verschlüsselt werden kann.
9.2 »Muss der Server zusätzlich via TLS gesichert werden oder besorgt Synapse eigenständig TLS-Zertifikate von bspw. Let’s Encrypt?«
Bei der Installation werden zunächst selbst signierte Zertifikate erstellt, die problemlos durch Let’s Encrypt-Zertifikate ersetzt werden können. Dies muss jedoch manuell vorgenommen werden.
9.3 »Wurde die Implementierung rund um Matrix/Riot/Synapse bereits auditiert?«
Mir ist nur bekannt, dass 2016 die Olm-Implementierung von der ncc group geprüft wurde.
9.4 »Wenn Du die Identitätsserver ausschliesst, können dann trotzdem auch User ausserhalb des eigenen Servers erreicht werden?«
Ja, Identitätsserver sind für den föderalen Betrieb in keinem Fall nötig. Der Vorteil der Identitätsserver ist, dass sich User nicht nur über die Matrix-ID hinzufügen können, sondern auch über Mailadresse und Telefonnummer.
Der Grund, warum Matrix die Identitätsserver nutzt, ist, dass sich ein Großteil der User mittlerweile nicht mehr vorstellen kann, dass man sich auch anders kontaktieren kann als über Telefonnnummern. Dass das beim E-Mail-System ja auch nicht nötig ist, ist zwar intuitiv bekannt, wird aber nicht als Prinzip auf andere Bereiche übertragen, warum auch immer.
Andere Matrix-User fügst Du jedenfalls über
»+« -> »Gespräch beginnen« -> »Mit ID einladen« -> »@user:example.com«
hinzu. Danach wie gesagt nicht vergessen, die IDs auch im Telefonbuch zu speichern, damit die Kontaktliste nicht nur von der Existenz des jeweiligen eigenen Matrix-Accounts abhängig ist und bei einem Wechsel des Matrix-Providers die Kontaktliste schnell wieder hergestellt werden kann.
9.5 Performance
Matrix braucht, soweit ich das aus meinen eigenen Tests feststellen konnte, in jedem Fall mehr Ressourcen als serverseitig Prosody und clientseitig Conversations. Da ich Matrix und Prosody problemlos parallel auf einem Cubietruck (Dual Core ARM, 2GB RAM – neben einem Seafile-Serverdienst) betreiben konnte, kann ich jedoch bestätigen, dass sich Matrix auch für den Betrieb auf ARM-Boards eignet (ob der 1GB Arbeitsspeicher eines Raspberry Pis ausreicht, kann ich jedoch nicht mit Sicherheit sagen – für rieseige Räume wie dem Matrix-HQ wird es sehr wahrscheinlich nicht reichen, für Freunde und Familie durchaus). In Bezug auf die Performance ist XMPP in jedem Fall im Vorteil – aber wie gesagt: Ich »zahle« gerne mit Performance, wenn ich dafür Zuverlässigkeit in der Nachrichtenübertragung und eine verlässliche »Client-Grundversorgung« erhalte.
9.6 Audio/Video-Fähigkeiten
AV-Fähigkeiten bringt Riot mit, funktioniert allerdings wie gesagt nur, wenn der jeweilige Server einen TURN-Serverdienst besitzt. Ich hatte das nicht erwähnt, weil Mike das bereits einmal in Skype: Welche freien Alternativen gibt es? erwähnt hatte.
Über den Autor | Gastbeitrag
Gastbeiträge werden von Autoren verfasst, die nicht zum festen Redaktionsteam des Kuketz-Blogs gehören. Bevor ein Gastbeitrag veröffentlicht wird, findet eine inhaltliche Abstimmung mit mir statt. Dabei übernehme ich die redaktionelle Bearbeitung des Textes, prüfe den Inhalt und bereite den Beitrag sorgfältig für die Veröffentlichung im Blog vor.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Element: Messaging über die Matrix – Messenger Teil7
Messenger: XMPP ist nicht der Heilsbringer – aber eine Lösung
Klimaschutz mit Datenschutz? Der große Elektroauto-Ladeapp-Test
Conversations: Messaging über das XMPP-Protokoll – Messenger Teil6
ejabberd: Installation und Betrieb eines XMPP-Servers
61 Ergänzungen zu “Messenger: Matrix – Das XMPP für Hobby-Admins?”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Ich finde diesen Artikel sehr gut!
Bei Matrix bin ich schon lange und ich finde auch,dass es mit Abstand der beste Messenger ist. Jabber nutze ich trotzdem auch,da es viel mehr Nutzer hat und dort einige Gruppenchats sind,die ich gerne nutze. Mir sind dort aber die ersten beiden von den von dir genannten Problemen schon begegnet – Das nervt! Das dritte wuerde ich genau anders herum bewerten,denn fuer Blackberry OS 10 gibt es zumindest einen Jabber Client,der nur Privatnachrichten unterstuetzt,waehrend man fuer Matrix nur die Riot APK nutzen kann.
Mit Jabber habe ich schon vor einigen Jahren angefangen,um beim Community Chat meines Webhosters teilzunehmen. Zusaetzlich habe ich mich dort privat mit einem Freund unterhalten. Auf den Gruppenchat hatte ich irgendwann keine Lust mehr und fuer den Privatchat habe ich tatsaechlich sogar eine Zeit lang Whatsapp benutzt. Heute koennte ich einen Wutanfall bekommen,wenn nur jemand den Namen Whatsapp ausspricht,weil es aus Datenschutzsicht ein Desaster ist und Facebook sich auch alle Muehe gibt,unbeliebteren Plattformen den letzten Todesstoss zu geben.
Vor ein paar Monaten hab ich dann Matrix gefunden und hatte bis heute nicht ein einziges Problem damit. Nachrichten werden zuverlaessig zugestellt,man sieht ueberall das gleiche und auch sonstige Fehler sind mir noch nicht aufgefallen. Obwohl das Protokoll soweit ich weiss noch relativ neu ist,zumindest im Vergleich zum sehr lange bestehenden Jabber,ist es sehr stabil. Seit ein paar Wochen bin ich erst wieder zurueck bei Jabber,wie gesagt wegen ein paar Gruppenchats,und die alten Probleme sind auch sofort zurueckgekehrt. Wenn ich an meinem Handy die Mobilfunkverbindung deaktiviere,um Akku zu sparen und dann in der Pause kurz reinschauen will,dann kommen Nachrichten in manchen Raeumen nicht nachtraeglich an,in anderen funktioniert es komischerweise.
Bei Matrix werde ich direkt mit hunderten Nachrichten ueberschwemmt beim Login und es hat noch nie eine davon gefehlt. Wie sollte ich einen Messenger mit so groben technischen Maengeln wie Jabber an weniger interessierte Nutzer weiterempfehlen?! Nachricht geht verloren -> Jabber ist scheisse,hol dir Whatsapp! Genau so und nicht anders wuerde der durchschnittliche Nutzer ohne jegliche Ahnung von Datenschutz reagieren.
Was hier im Artikel jedoch wichtiges vergessen wurde: Matrix funktioniert auch ganz ohne Handy mit nur einem Computer! Fuer Jabber trifft das auch zu,wobei ohne staendig aktive Verbindung mit einer hoeheren Anzahl verlorener Nachrichten zu rechnen ist. Die meisten anderen Messenger unterstuetzen das jedoch gar nicht und setzen zur Nutzung einer Webapp,die nichtmal fuer alle verfuegbar ist,zwingend ein Handy voraus,das den persoenlichen Vorlieben der Firma hinter dem Messenger entsprechen muss.
Danke Niklas für den Kommentar und die Bestätigung meiner Erfahrungen mit XMPP.
…sagen wir mal so: ich habe diesen Punkt nicht sonderlich stark gemacht, aber genau dieses wichtige Merkmal mit folgender Aussage gemeint:
Um es konkreter zu machen werde ich, wenn ich Mike die gewünschten Updates schicke, diesen Punkte durch Folgendes ergänzen lassen:
Besser?
Ja,so ist es deutlicher.
Gerade wenn man sich auch mal die Systeme der open source Liebhaber anschaut (Ubuntu Mobile,Sailfish OS,…) ist es wichtig,dass der Chat ohne kompatibles Handy trotzdem am PC genutzt werden kann.
Ganz genau. Ich will nie wieder missen, einem Smartphone-Verlust völlig gelassen hinnehmen zu können. Ich finds schon Hammer, dass das Problem der Nummernbindung der „walled garden“-Fraktion selbst dann nicht auffällt, wenn sie ihr Handy verloren haben… ich frag mich immer, warum dieser Vorteil von einem allen selbstverständlichen System (Email) nicht auf andere Bereiche als Feature-Anspruch übertragen wird.
Der Artikel ist sehr datenschutzlastig. Essentielle Security-Fragen werden (aktuell) nicht behandelt. Beispiele:
– Ist die Ende-zu-Ende Verschlüsselung standardmäßig aktiv?
– Muss der Server zusätzlich via TLS gesichert werden oder besorgt Synapse eigenständig TLS-Zertifikate von bspw. Let’s Encrypt?
– Wurde die Implementierung rund um Matrix/Riot/Synapse bereits auditiert?
– […]
Aus Datenschutzsicht sind die Default-Einstellungen, wie Roland es im Artikel allerdings auch hervorhebt, nicht optimal. Das kann man zwar ändern, aber datenschutzfreundlich wäre natürlich schöner.
Ich habe Roland gebeten, eventuell noch ein »Addon« nachzuliefern, dass auch die Sicherheit beleuchtet. Denn ein datenschutzfreundlicher Matrix-Server, der sauber funktioniert ist nur dann sinnvoll, wenn die Sicherheit nicht zu kurz kommt.
XMPP…Matrix…Riot…Verschlüsselung…alles schön und gut, aber leider für Otto Normalverbraucher gänzlich ungeeignet. Sprich den durchschnittlichen WhatsApp-User von 10 bis 80 Jahren. Der „Volksmessenger“ muss einfach und selbsterklärend funktionieren. Da möchte sich keiner mit Schlüsseltausch, Verifizierung von Kontakten etc. auseinandersetzen. Das sind Themen für eine kleine Randgruppe von Enthusiasten, die sich um Datenschutz und Privatsphäre kümmern, zu denen ich auch gehöre. Aber hinsichtlich der Probleme, die sich einem beim Benutzen von XMPP oder Riot eröffnen, kann ich keinen WhatsApp-Nutzer zum Umschwenken gewinnen. Wenn überhaupt, dann maximal zu wire (weil kostenlos) oder Threema. Und dahin nur, wenn ich demjenigen eine Lizenz subventioniere, sprich schenke. Alle Sicherheitsaspekte müssen für den Normalo im Hintergrund ablaufen, von Anfang an aktiv, ohne in die App irgendwie eingreifen zu müssen. Conversations ist für Android zwar klasse, für mich als ChatSecure Nutzer bin ich wieder außen vor, weil das keine Verschlüsselung in Gruppenchats erlaubt, und bei Riot war noch nicht einmal herauszufinden, wie ich mit einen Kontakt chatten kann, obwohl der im Adressbuch steht, aber in der Riot-App nicht gefunden wird. Irgendwann mal ging es, aber solche leraning-by-doing-Aktionen kann ich keinem zumuten, der wechselwillig ist und einen Messenger sucht, der auf Anhieb funktioniert. Solange es solche (und derer noch mehrere) Missstände gibt, bleibt die Masse bei WhatsApp, ein größerer Teil verteilt sich auf Telegram, facebook-Messenger, der Rest auf Threema und wire. Und solange conversations, Chatsecure etc. eher „Freizeitprogrammierungen“ sind, die nach dem Hörensagen-Prinzip versuchen an Verbreitung zu finden, wird sich an selbiger leider nichts ändern.
Danke für den Beitrag. Ich habe mich in den letzten Monaten auch damit beschäftigt und ich kann zumindest sagen, dass der obige Punkt mittlerweile „überholt“ ist. Seit Mitte November ist im Riot-Client für iOS PushKit/CallKit implementiert. D.h. Push-Nachrichten müssen nun nicht mehr mit den eigentlichen Nachrichteninhalten (message content) verschickt werden um als Benachrichtigung direkt lesbar zu sein (z.B. im Sperrbildschirm, Mitteilungszentrale, etc.). Der iOS-Client holt bzw. synchronisiert nun auch – genau wie der Android-Client – die Nachrichteninhalte direkt vom jeweiligen Matrix-Server des Benutzers (home server) und es müssen keine sensiblen Inhalte mehr an Apple oder Google übertragen werden. Man kann daher die Option: ‚redact_content: true‘ immer setzen und trotzdem Benachrichtigungen samt der realen Nachrichteninhalte unter iOS erhalten (Anmerkung: nur wenn im iOS-Client die Option ‚Zeige entschlüsselten Inhalt‘ aktiviert ist). Zudem wurde ein sogenannter `event_id_only` Push-Modus eingeführt, den alle neueren Riot-Clients nutzen und wo nur noch `event ID` sowie `room ID` in der Push-Nachricht (an bzw. von Apple/Google) enthalten sind. D.h. auch wenn die Option: ‚redact_content: false‘ gesetzt ist, werden damit keine Nachrichteninhalte mehr an Dritte übertragen.
Die Option `redact_content` wurde zwischenzeitlich in `include_content` umbenannt und muss nun für den gleichen Effekt wie vorher (d.h. für grantiert entfernte Nachrichteninhalte) auf `include_content: false` stehen. Siehe dazu: https://github.com/matrix-org/synapse/commit/7190a550dc766a820f27781b33a990cb0769e731
Danke Norbert. Darf ich Deine Anmerkung so mit in die Artikel-Nachträge übernehmen?
Hallo Roland, klar darfst du das. Ich hab bei der Textformatierung wohl etwas gepennt und auch das die Option in ‚include_content‘ umbenannt wurde habe ich erst nachträglich angemerkt bzw. wurde dann von Mike an den ursprünglichen Kommentar angehängt. Eventuell kannst du ja den Text noch etwas anpassen, z.B. an deinen Schreibstil etc. :)
Vielen Dank für den sehr informativen Artikel. Ich würde gerne matrix mit Riot intensiver nutzen, da auch bei mir häufiger xmpp Nachrichten verschwinden oder nicht über sämtliche Geräte synchronisiert werden.
Allerdings kommen Nachrichten bei Riot auf android bei mir nur an, wenn Riot geöffnet ist. Ich nutze Lineage OS ohne google-apps und Riot aus f-droid. Nach meinem Kenntnisstand ist das ohne GCM derzeit immer so. Das ist derzeit für mich noch ein KO-Kriterium. Ein Messenger, den man starten muss (bzw. in den Vordergrund holen muss), um neue Nachrichten zu erhalten, ist nicht wirklich praktikabel. Weiß jemand, ob dazu Abhilfe geplant ist?
Dies kann ich nicht bestätigen. Riot für Android benutzt bzw. unterstützt ohne vorhandene Google-Dienste konfigurierbares Polling samt Hintergrunddienst und sollte daher problemlos Nachrichten auch im Hintergrund (d.h. nicht geöffnet) empfangen können. Der Akkuverbrauch steigt dadurch allerdings an bzw. liegt damit höher als mit GCM/FCM und man sollte eventuell die Grundeinstellungen etwas verändern (Intervall erhöhen etc. – aber mit Vorsicht und Stück für Stück austesten). Außerdem wäre es in diesem Fall ratsam, sich nur in wichtigen Räumen benachrichtigen zu lassen bzw. sich auf diese zu beschränken und riesige Chaträume mit entsprechend hoher Frequenz an neuen Nachrichten stumm zu schalten. Wichtig ist, dass man Riot ohne GCM/FCM (bzw. Google-Dienste) von der Akku-Leistungsoptimierung auschließt: Android Einstellungen -> Akku -> Mehr -> Akku-Optimierung -> Riot auf „Nicht optimiert“ stellen. Andernfalls wird Riot (gilt natürlich auch für andere Apps) samt Hintergrundienst nach kurzer Zeit einfach abgewürgt.
Danke für den Hinweis: hast Du unter „F-Droid-Riot“ unter Settings „Start on boot“ akiviert?
Ja – hab ich aktiviert. Bei mir funktioniert die in der F-Droid-Version von Riot entschärfte Grundeinstellung (Standardeinstellung) bezüglich Polling sehr gut und der Akkuverbrauch ist damit kaum feststellbar, auch wenn dadurch Nachrichten minimal verzögert ankommen (stört mich aber nicht).
Ich muss aber mit erschrecken feststellen, dass die F-Droid-Version von Riot mittlerweile uralt ist (vom 20-10-2017) und sogar mit unvollständiger Übersetzung daherkommt. Was ist da los?
Die Frage bez. „Autostart“ ging eigentlich an Rainer. ;)
Zu Deiner Frage: heute kam ein Riot-FDroid-Update auf 0.7.09 (vorher: 0.7.03). Die F-Droid-Builds hinken doch immer ein bisschen hinterher… ich will nicht wissen, was da an ehrenamtlicher Arbeit drinsteckt, da die F-Droid-Devs ja alles selbst kompilieren. Ich hoffe nur, da kommen halbwegs Spenden rein, damit die Arbeit zumindest ein wenig kompensiert wird.
Naja Matrix hat für mich schon zu grobe Datenschutz Patzer und es stand lange eine Millionenschwere Firma dahinter. Dazu ist die Entwicklung zentral organisiert. Wenn andere Entwickler den Standard um eigene Funktionen erweitern wollen geht das nur auf Gutdünken der Matrix Foundation. Kann man gut oder schlecht finden.
Und man kann sich natürlich die Frage stellen warum die Entwickler nicht XMPP vorangetrieben haben statt alles neu zu machen. Dass das geht sieht man ja. Nun haben wir zwei Protokolle die nicht kompatibel zueinander sind insbesondere unter berücksichtigung der E2E Verschlüsselung. Daniel Gultsch hat ja schon angedeutet dass es mit ihm keine Transports geben wird. Also wozu das ganze?
Matrix hat noch nicht die Nutzerbasis und bis es soweit ist hat XMPP das Clientproblem gelöst. Ich finde da sollte man lieber an einem Strang ziehen.
Hi Anonymous, danke für die Anmerkungen.
Wie gesagt: solange es opt-out ist, die Software öffentlich untersuchbar und dafür im Gegensatz zu XMPP funktioniert (meine Erfahrung bezüglich der verschwundenen Nachrichten scheint sich ja hier vielfach zu bestätigen), halte ich das für vertretbar.
Laut FAQ:
Und ich dachte, dass ich das „wozu das ganze?“ schon zu deutlich in meiner Argumentation zum Ausdruck gebracht hatte, aber hier nochmal in Kurzform: Matrix ermöglicht freie, föderale Netze wie XMPP, die am Ende allerdings im Gegensatz zu XMPP auch wirklich so funktionieren, wie es die WhatsApp&Co-gewöhnten User erwarten. Bei XMPP war das in meinem mehrmonatigen Testzeitraum nicht der Fall und Frustration das Ergebnis, vor allem bei den Usern. Ergo: eine digital mündige Zivilgesellschaft (der Grund dessen, warum ich mich mit IT beschäftige) lässt sich nach meinem Erfahrungsstand, den hier ja auch viele bestätigt haben, aktuell nicht umsetzen.
Davon abgesehen: hättest Du einen Link für das Statement von Daniel Gultsch? Würde mich interessieren.
Das ist Konkurrenzdenken, das, so zumindest lese ich die oben verlinkten FAQ, nicht im Sinne der Matrix-Entwickler ist. Ebenso ist es auch nicht mein Anliegen gewesen, Konkurrenz zu schaffen, sondern Matrix als Ergänzung für IT-Laien vorzustellen (was eigentlich bereits aus der Einleitung hervorgehen sollte).
Davon abgesehen: dafür, dass XMPP seit wieviel Jahrzehnten Zeit hatte, sich zu etablieren, halte ich „Konkurrenz“, wenn man Matrix unbedingt als solche sehen möchte, doch für ganz gut, vor allem in Bezug auf die besagte „Slack-Seuche“. Die Slack-User wirst Du mit XMPP schwer bekommen, mit Matrix schon.
Unter JabberGultsch
Klar wenn man nen dicken Sponsor hat geht das. Ich weiß nicht was das Geschäftsmodell des Unternehmen war aber Datenschutz wird es nicht gewesen sein. Von Slack weiß ich gar nichts, ob ich die damit nicht kriege wird sich zeigen, im Zweifel können die gerne in ihrer zentralen Blase bleiben.
Ein Hobby-Admin der keine Zeit für ne vernünftige Konfig hat, wird im Zweifel auch die Sicherheit vernachlässigen so wie der Author in diesem Artikel (Verzeih, weiß nicht wie ich den Hinweis sachlicher ausdrücken könnte). Letztlich sind deine Argumente ja gut und richtig, in der Praxis wird die weitere Fragmentierung sich aber nicht vermeiden lassen und man muss dem Laien erklären warum die Situation so vermurkst ist.
Danke für den Link.
Ich glaube, es gehört schon etwas mehr dazu als nur viel Geld, als, soweit ich es mitbekommen habe, einzelner Entwickler ein zuverlässiges Protokoll auf die Beine zu stellen, inkl. plattformübergreifender Referenz-Clients, die nicht nur eine „proof of concept“-Studie sind.
Und was auch immer das Geschäftsmodell der Firma war (Details verrät vielleicht der Matrix-Spendenaufruf?): immerhin ist ein freies Protokoll dabei herausgekommen, das eben nicht nur für Messenger taugt, sondern sich auch auf dem Feld der kollaborativen Messenger wie Slack und Mattermost behaupten kann.
Die Herangehensweise ist mir, sorry, zu trotzig. Schau dir Slack mal an und bewerte dann meine Aussage neu, dass Matrix hier zwei Welten verbinden könnte, denn man muss den Usern schon irgendwie auf halber Strecke entgegenkommen. Für mich bedeutet das, ihnen ein Messenger-System anzubieten, das „Spaß“ macht und zuverlässig funktioniert, ich aber im Gegenzug verlangen kann, grundlegende Freiheitsgedanken (Offenheit und Dezentralität) neben Usability-Aspekten als Bewertungskriterium auch von Seiten der User erwarten zu können.
Bisher fand ich den Austausch herausfordernd und spannend, jetzt werden mir Deine Aussagen arg oberflächlich und beliebig in den Schlussfolgerungen. Überleg nochmal, ob es das erklärte Ziel meines Artikels war, zu beschreiben, wie man einen Server, auf dem Matrix läuft, IT-sicherheitstechnisch absichert oder ob sich aus dem Artikel ernsthaft ableiten lässt, wie umfangreich meine Kenntnisse zu IT-Sicherheit sind.
(Der Ton gefällt mir besser, danke.)
Ist es Ziel des Artikels, Fragmentierung zu vermeiden? Matrix will doch schon von Grund auf eine Antwort darauf anbieten, „das Fragmentierte“ zu verbinden – und nicht die Fragmentierung zu unterdrücken.
Was ist vermurkst? Die Messenger-Vielfalt? Der Zustand von XMPP? Matrix?
Wie auch immer: meine Erfahrung ist, dass „Laien“ nur dann offen für Erklärungen sind, wenn dabei am Ende auch etwas Benutzbares heraus kommt. Die Offenheit und Dezentralität von XMPP als zivilgesellschaftlicher, demokratischer Ansatz hatte auf der theoretischen Ebene alle überzeugt, die ich zunächst überzeugen konnte, XMPP eine Chance zu geben. Wenn die Umsetzung aber dazu führt, dass die Nachrichtenübertragung Glückssache ist, werden sich alle wieder nach der „guten alten Diktatur“ in Form zentralisierter Messenger sehnen und mir im besten Fall mitleidig auf die Schulter klopfen.
Die besagten Probleme von XMPP bestehen nicht mehr? Wunderbar. Wieviele XEP-Erweiterungen muss ich dafür konfigurieren und dann auf Nachfrage in irgendwelchen Dev-Chats erfahren, dass die Doku für diejenigen, die bei mir nicht den gewünschten Effekt erzielen, nicht mehr aktuell sind (Grüße an Zash im Prosody-Devchat)? Wieviele Dokus für wieviele Clients schreiben? Nochmal: ein zivilgesellschaftlicher Ansatz, der nur dann funktioniert, wenn sich am Ende nur eine „Elite“ um die Umsetzung kümmern kann, wird in meinen Augen nicht dazu führen, dass sich auf breiter Ebene zivilgesellschaftlich kontrollierbare IT-Infrastrukturen bilden, die dem status quo an zentralisierten Messengern entgegen treten können. Ich sage nicht, dass man diesen Umstand so wie ich problematisieren muss, sondern habe nur dazu eingeladen, die Sache aus meiner Perspektive zu betrachten.
Ich habe nach wie vor einen XMPP-Account, will aber nicht Teil einer „XMPP-User-Elite“ sein, weil das nicht meine Vorstellung von einer digitalen Zivilgesellschaft ist. Wer sich in der „XMPP-User-Elite“ wohl fühlt, völlig okay – die sind dann aber auch nicht unbedingt Teil der Zielgruppe, die ich ansprechen wollte.
Ändert sich bei XMPP derart etwas, dass Matrix obsolet wird (allein schon aus Performance-Gründen würde ich das durchaus begrüßen), würde ich mich riesig freuen. Bis dahin gilt meine im Artikel formulierte Einladung, mit Matrix das zu bekommen, was man sich von XMPP eigentlich erhofft hatte: in der Übertragung wirklich zuverlässige, dezentrale, freie Messenger-Strukturen.
Danke. Schließe mich dir an. Matrix hat keinen fundamentalen Gewinn, spaltet aber die Gegenbewegung!
Hallo JoeDoe, ich weiß nicht so recht, ob Du meinen Artikel überhaupt komplett gelesen hast. Ich denke nicht, dass man den Umstand, dass Matrix auch für WhatsApp&Co-gewöhnte User im Gegensatz zu XMPP sauber funktioniert, kein „fundamentaler Gewinn“ ist.
Zum Thema „Spaltung“ sage ich hier nochmal auf die FAQ. Es geht nicht um Spaltung, sondern darum, födeale/offene/freie Netze vermittelbar voranzubringen. Aber wie bereits zu Anonymous gesagt hielte ich auch in Anbetracht der immensen Entwicklungs-Vorlaufzeit, die XMPP für sich verbuchen kann, selbst eine explizite Konkurrenz für gut, wenn dies dazu führt, dass ein tolles, „geschichtsträchtiges“ Protokoll wie XMPP ein wenig mehr im 21. Jh. ankommt.
An alle nachfolgende Kritik dieser Form: vor dem Lesen bitte nochmal genau überlegen, ob man meinen Artikel wirklich darauf reduzieren kann, dass ich sagen wollte „Matrix gut, XMPP schlecht“. Es geht im Artikel nicht darum, XMPP zu ersetzen, sondern das erstrebenswerte Ziel freier, föderaler IT-Infrastrukturen so zu ergänzen, dass auch IT-Laien mit an der Umsetzung an einer entsprechenden digital mündigen Zivilgesellschaft arbeiten können. Ich hoffe, dass ich das auch hier nun nochmal deutlich gemacht habe und bitte darauf zu verzichten, meinen Artikel nur als erneuten Aufguss der nie endenden Messenger-Debatte zu sehen. Danke.
Gräm dich nicht Roland. Bei vielen Kommentaren meiner Artikel ist es nicht anders: Die Leute überfliegen den Inhalt oftmals oder reduzieren ihn auf eine Aussage. Bei einigen Kommentaren fragt man sich anschließend, ob der- / diejenige den Artikel auch tatsächlich gelesen und verstanden hat (oder man sich schlecht ausgedrückt hat).
Ich sehe den Nutzen von Kommentaren vor allem in der Kritik. Da steckt Potenzial zu Verbesserung / Dialog / Änderung. Es ändert nichts nochmal alles aufzuzählen in welchen Punkten man dem Author zustimmt:
Top! Ich stimme dir in allen Punkten zu.
Ah ja vielen Dank für das Lob.
Alle sind sich einig, alles gut. Ein kurzes Lob für das wesentliche reicht da auch.
Ja das war bei uns auch mal so. Inzwischen gibt es keine Probleme mehr und bis auf die iOS Nutzer sind alle zufrieden was sich ja bald ändern dürfte. Es funktioniert also auch für Technikunbedarfte. Muss dazu sagen dass alle MUCs über ejabberd Server laufen.
Ich wollte auch nicht andeuten das Matrix sich aufmacht XMPP zu ersetzen. Das oder weitere Spaltung wie JoeDoe anmerkte ist aber die Konsequenz, wenn man nicht dieselbe Sprache spricht, dann kommt kein Dialog zustande. In der Praxis kommt es also darauf an ob du XMPP oder Matrix nutzt. Manche werden sich als Lösung genervt Messenger für beide installieren neben den fünf die sie eh schon haben andere werden keine Lust mehr auf ständig was neues haben.
Für den verwöhnten WhatsApp Nutzer ist unerheblich welches weniger Konfiguration bedarf.
Lieber Roland,
ich denke, mein Kommentar und der von „Anonymous“ zuvor enthielt ganz wesentliche Kritikpunkte dafür, statt nen XMPP-Server einen mit Matrix aufzusetzen, und zwar, den der Fragmentierung der Gegenbewegung und des dafür nicht relativ großen Vorteils von Matrix.
Ich kann dir das auch gerne etwas genauer erläutern, auch wenn ich nicht weiß, ob dir das sonderlich Recht ist: Es ist ein Standardproblem bei jeder Gegenbewegung, sei es nun in der Politik, die Friedensbewegung, im Krieg in Syrien, die Linken…. allen Parteien, überall wird „Teile und Herrsche“ versucht vom Gegner zu anzuwenden. Daher sehe ich auch in der Infomatik die Gefahr, dass statt dass alle an einem Strang ziehen, zuviele verschiedene aber ähnliche Projekte gleichzeitig laufen – ob nun bewusst gesteuert oder nicht. Das ist zum Beispiel ähnlich bei den freien Fracebook-Alternativen so. Es gibt Friendica, Hubzilla, Diaspora, Pump-io, GnuSocial, mastadon….
Wahrscheinlich siehst du das nicht so als ein großes Problem an. Nun gut, aber das hängt zum Beispiel auch mit deinem Hauptkritikpunkt an XMPP zusammen. Dein Hauptkritik in deinem Artikel ist, dass der Prosody-Server nicht so zuverlässig läuft. Nun, soll ich dir was sagen, ich weiß auch woran das liegt, es liegt daran, dass an Prosody eigentlich nur 2 Leute arbeiten, und sonst keiner Zeit und Lust hat da freiwillig seine Freizeit für andere zu opfern. Mit ein paar mehr Helfern, würde sich deine Kritik an Prosody in Luft auflösen, die entsprechenden Erweiterungen wären gestern schon fertig. Und dadurch, dass man dann noch ein ähnliches neues Projekt angreift wie z.B. Matrix wird es nicht besser!
Im Übrigen, finde ich deinen Vergleich auch etwas einseitig. Matrix wurde gestartet da gab es die Erweiterungen zu Verbesserungen im mobilen Bereich noch nicht, inzwischen gibt es Push und MAM. Für viele sehr kritische Sachen wie fehlende Alternativen zu Push über Google bei Matrix werden dagegen heruntergespielt. Zudem betreibe ich selbst einen XMPP-Server und ja, du hast Recht, es war nicht so ganz toll mit allen Erweiterungen einen reibungslosen Betrieb hinzubekommen, und Chatsecure hinkt auch noch hinterher, aber mit Matrix wirds nicht besser.
Ein kleiner konstruktiver Vorschlag von mir: Ich persönlich hätte es besser gefunden, du hättest dich in deinem Artikel dafür entschieden, ob du einen Vergleich zwischen XMPP Matrix machst, und das dann genauer, ODER ob du das ausklammerst, und dann eine schöne Anleitung gibst, wie man so einen Matrix-Server aufsetzt und was man damit Schönes machen kann.
Schöne Grüße & trotz Kritik weiterhin viel Elan für das Gute!
Joe Doe
Tut mir leid, ich habe immernoch das Gefühl, dass Du meinen Artikel allenfalls überflogen hast. Wie kann mand enn keinen „großen Vorteil“ darin sehen, dass das eine System clienübergreifend sauber Nachrichten übertrug und das andere nicht?
Wenn ich bei einem System immer das Gefühl habe, nicht sicher sein zu können, ob eine wichtige Nachricht tatsächlich ankam oder nicht, macht es im Alltag nur Stress, den ich mir auf keinen Fall geben will, wenn ich schon den administrativen Aufwand habe.
Wenn Nachrichtenverlust (der hier ja auch vielfach von anderen bestätigt wurde) für dich okay ist, schön. Ich will aber sichergehen, dass Nachrichten ankommen, sonst ist das System für mich schon in seiner Minimalanforderung unbrauchbar.
Bei aller Kritik an neoliberalen Freiheits-Dogmen: ich betrachte es durchaus als Vorteil, dass sich im Netz, wann immer sich der Bedarf ergibt, (zumindest aktuell noch) Gegenbewegungen bilden können. Auch XMPP hat von diesem Umstand profitiert. Und am Ende ziehen alle diese Projekte an einem Strang: die besten Möglichkeiten dafür zu finden, als digitale Zivilgesellschaft die IT-Infrastukturen frei gestalten zu können.
Ich vertraue aktuell auf den Anspruch des Matrix-Projekts, keine Gegenbewegung zu irgendwas sein zu wollen, sondern Brücken zu allen Systemen anzubieten, die das erlauben (wollen). Die Bridge zwischen Matrix und Slack, obwohl Slack ja 0 Interesse daran haben dürfte, funktioniert zum Beispiel sehr gut., was für mich in Projektarbeiten bedeutet, dass ich meinen Anspruch an Nutzung ausschließlich zivilgesellschaftlicher kontrollierbarer Systeme wie Matrix bewahren kann und trotzdem mit denen kommunizieren kann, die Usability (noch) über alles andere setzen.
Ich sehe das also deswegen nicht als Problem an, weil ich nicht wüsste, ob es eine Alternative zu einer freien Entwicklungsphilosophie gäbe, die den Anspruch an freiheitlicher Entwicklung (jede*r darf forken/neu entwickeln, wenn er*sie es für nötig hält) bewahrt.
…also ehrlich gesagt: ich hing ein paar Monate mit im Prosody-Devchat. Selbst wenn ich Informatiker wäre müsste ich mir doch sehr überlegen, ob ich mir den besagten 2 Entwicklern zusammenarbeiten wollen würde. Es hatte für mich nach einer Weile allerhöchstens noch unterhaltsamen Wert, dass der*die eine von beiden zu 90% mit oder über seinen Bot mit der Außenwelt kommuniziert. Ist in dem Zusammenhang, dass sie keine Spenden annehmen, vielleicht ein Indiz dafür, dass hier Menschen sitzen, die einfach ihre eigene Suppe kochen wollen und deswegen auch wenig Interesse daran haben, weniger Informierten eine saubere Doku zur Verfügung zu stellen, was völlig okay ist, mir aber nicht hilft und ich deswegen am Ende weiterziehe.
…es „wird nur dann nicht besser“, wenn Du als „besser“ nicht gelten lässt, dass das eine tut, was es verspricht und das andere nicht. Push und MAM haben halt bei mir nicht dafür gesorgt, dass der Nachrichtenfluss reibungslos funktionierte. Wenn das für Dich kein Argument ist, okay, für mich ist es eins.
Ich habe auch keinesfalls etwas heruntergespielt, sondern genügend Nachteile aufgezählt. Am Ende sah die Gleichung aber so aus: aus einer Reihe von dezentralen Messenger-Lösungen funktioniert aktuell nur eine einzige (Matrix) so, dass sie einen auch von Laien erwarteten Funktionsumfang zuverlässig bietet. Jetzt kann ich die Nachteile mit dem Datenschutz als Grund nehmen und wieder Signal nehmen – und den Grundgedanken von Föderalität dabei aufgeben. Die Argumentation für zivilgesellschaftliche kontrollierbare föderale Systeme war in meinem Artikel so, dass ich an oberste Stelle Offenheit und Föderalität setze und das zu einem System führt, was wirklcih benutzbar ist – erst dann unterhalte ich mich über Verschlüsselung und Datenschutz. Denn wenn ich Datenschutz und Verschlüsselung an den Anfang setze, gebe ich im Zweifel Offenheit und Föderalität auf, denn WhatsApp verschlüsselt wunderbar, wenn ich mit der propr. Software ein Problem habe nehm ich Signal, bin aber in beiden Fällen wieder in einem „walled garden“. „Walled gardens“, egal ob offen oder proprietär, ob datenschutzkonform oder nicht, ob IT-sicherheitstechnisch gut gelöst oder nicht, können für mich nicht die Grundlage einer digitalen Zivilgesellschaft sein, weil hier Gesellschaft vertikal und nicht horizontal gedacht wird.
Ja, hätte man machen können, zu beidem gibt es aber genügend im Netz. Mein Anspruch war, Matrix als Ergänzung für Mikes Empfehlungsstrecke vorzustellen und dies in einen Erfahrungsbericht von jemandem zu verpacken, der mündiges Mitglied einer digitalen Zivilgesellschaft sein will, in der auch IT-Laien in der Lage sind, einen administrativen Beitrag zu leisten. Ob ich diesem eigenen Anspruch gerecht werden konnte, wird sich natürlich zeigen, ob mein Server in 5 Jahren immernoch läuft.
…danke für den Austausch. Ich hoffe „trotz Kritik“ auf zivilgesellschaftliche Zusammenarbeit, an welcher „Front“ auch immer. ;)
Mag sein. Mir ist „bald“ aber zu beliebig und nach mehrmonatigen Tests hatte ich schlicht irgendwann keine Lust mehr. Für mich soll, bei aller Begeisterung für Technik, diese kein Selbstzweck werden und wenn man nächtelang Fehler analysieren muss, fragt man sich schon irgendwann, ob der Preis der Freiheit wirklich so hoch sein muss, wenn „neben“ eine funktionierende Lösung, die ebenso frei ist, wartet.
Ich hoffe wie gesagt, dass sich beide Fraktionen um ein Bridging bemühen, dann wird das schon klappen. Abwarten.
Hallo Roland,
Danke für den spannenden Artikel. Deine „zivilgesellschaftliche“ Sicht kann ich nur voll unterstützen. Deshalb viel Erfolg bei Deinen Projekten. Gerade im unversitären Umfeld finde ich es sehr wichtig, dass man aus dem Mainstream herausfindet. Das hat hoffentlich Vorbildfunktion…
Aber nun noch eine „blöde“ Frage:
Wenn Du die Identitätsserver ausschliesst, können dann trotzdem auch User ausserhalb des eigenen Servers erreicht werden?
Danke, ich versuche, engagiert zu bleiben.
Zu Deiner wichtigen Nachfrage, die ich im Update dann nochmal konkretisieren werde:
Identitätsserver sind für den föderalen Betrieb in keinem Fall nötig. Der Vorteil der Identitätsserver ist, dass sich User nicht nur über die Matrix-ID hinzufügen können, sondern auch über Mailadresse und Telefonnummer. Ich mag keine Telefonnummernbindung, sondern notiere mir Messenger-IDs wie Email und Telefonnummern im Telefonbuch, um unabhängig von der Telefon-Infrastruktur bleiben zu können. Dies empfehle ich auch allen, die ich von dezentralen Messengern überzeugt habe.
Der Grund, warum Matrix die Identitätsserver nutzt, ist, dass sich ein Großteil der User mittlerweile nicht mehr vorstellen kann, dass man sich auch anders kontaktieren kann als über Telefonnnummern. Dass das beim Email-System ja auch nicht nötig ist, ist zwar intuitiv bekannt, wird aber nicht als Prinzip auf andere Bereiche übertragen, warum auch immer. Hier beginnt dann „Aufklärungsarbeit“.
Andere Matrix-User fügst Du jedenfalls über „Gespräch/Chat beginnen -> „Über Matrix ID hinzufügen“ -> Eingabe der ID (immer die Form @user:example.com) hinzu. Danach wie gesagt nicht vergessen, die IDs auch im Telefonbuch zu speichern, damit die Kontaktliste nicht nur von der Existenz des jeweiligen eigenen Matrix-Accounts abhängig ist.
Hallo Roland,
deine Erfahrungen mit XMPP kann ich zum Teil bestätigen. Eine Weile hatte ich auch überlegt zu Matrix zu migrieren stand dem Protokoll aus bereits genannten Gründen aber schnell skeptisch gegenüber. Riot habe ich mir trotzdem mal angeschaut, konnte mich jedoch nicht damit anfreunden. Wenn es Alternativen für Linux und Android (F-Droid) gibt die du empfehlen kannst würde ich mir die mal anschauen.
Ein weiterer Grund der mich vom Wechsel abhielt war dass ich bereits zweimal mit viel Mühe alle in meinem Umfeld zum Wechsel bewegen konnte. Erst zu Signal, dann zu XMPP. Einige haben sehr deutlich gemacht dass sie einen weiteren Wechsel nicht mitmachen werden und so bin ich froh dass die meisten Probleme behoben sind.
Es spricht zwar nicht für das Protokoll doch was mich auch persönlich auch so an XMPP überzeugt ist dass fünf der Entwickler in Deutschland leben, drei habe ich bereits selbst getroffen. Das ist für mich ein enormer Sympathie und Vertrauensbonus. Ich denke dass diese Nähe zu den Entwicklern auch andere XMPP-Fans begeistert. Und es ist auch eine Chance für das in Deutschland vergleichsweise ausgeprägte Datenschutzbewusstsein den Standard mitzugestalten. Von Gultsch weiß ich das manche Unternehmen ihn mit Forks und exlusiven Features beauftragen die für den Einsatz im eigenen Unternehmen wichtig sind.
Hallo Ormendahl,
danke für Deine Anmerkungen.
Ich wüsste nicht, dass es bereits andere Client-Implementierungen für Android gibt. Was genau stört Dich denn an Riot?
Kann ich sehr gut nachvollziehen. Den Wechsel von XMPP zu Matrix konnte ich nur mit einem solidarischen Aspekt durchführen, da zum akt. Zeitpunkt damals ChatSecure wie gesagt absolut unbrauchbar war und so die iOS-User gänzlich ausgeschlossen waren, daher: „Entschuldigt die Bitte, aber würdet ihr nochmal einen Wechsel über euch ergehen lassen, damit die iOS-User auch teilnehmen können?“
Naja, geographische Nähe kann vielleicht ein Bonus sein, um sich einfacher zu treffen, muss es aber nicht mehr. „Meine“ Uni arbeitet zum Beispiel sehr gut mit den Seafile-Devs aus China zusammen, auch mit regelmäßigen persönlichen Treffen auf Cloud-Conventions. Hier wäre Nextcloud sicher geographisch sinnvoller gewesen, aber geographische Distanzen müssen im digitalen Zeitalter absolut kein Hindernis mehr sein. Oder anders: ich vertraue Mikes Artikeln auch nicht, weil er in Deutschland lebt, sondern weil ich sie inhaltlich schlüssig finde. Deine Aussage lässt sich zumindest ein wenig in die Richtung deuten, dass „Vertrauen“ mit „nationaler Nähe“ korreliert. Da das Konzept von „Nationalität“ für mich nicht mehr ist als ein Stück Papier in Form eines Passes, der irgendwann von irgendwem mal aus machtpolitisch-wirtschaftlichen Gründen eingeführt wurde, versuche ich, nicht in in diesen Kategorien abzuwägen (obwohl ich natürlich auch nie ganz frei davon sein kann durch entsprechende gesellschaftliche Vorprägung). Ich denke allerdings, dass der Matrix-Hauptentwickler (Matthew Hodgson) genauso gut und gerne gegen entsprechende Bezahlung bestimmte Features umsetzen wird wie Daniel Gultsch.
Nur zur Sicherheit: auch wenn Du Deine Formulierung nicht in diese Richtungen ausgelegt haben wolltest, hab ich in ihnen einen Anlass gesehen, an dieser Stelle für eine internationale, digitale Solidarität zu plädieren: Vertrauen und Sympathie schenken sollten wir uns unabhängig geographischer oder nationaler Kategorien, weil wir alleals globale, digitale Zivilgesellschaft vor den gleichen Problemen stehen, das nichts mit Geographie oder Nationalität zu tun hat: wirtschaftliche Überwachung kennt keine Nationalität und keine geographischen Grenzen, weil finanzielles Gewinnstreben keine Nationalität oder geographsichen Grenzen kennt.
* Mir ist aufgefallen dass Riot direkt nach dem Start eine Verbindung aufbaut noch bevor ich etwas tat. Ich habe dann Google-Analytics im Code entdeckt allerdings nur in der Google Play Version und immerhin Opt-in. Ich hatte Sorge dass sich das ins negative ändern könnte wenn Matrix eine kritische Nutzerzahl erreicht. Mit einem unguten Gefühl habe ich es mir dann angeschaut.
Update Riot hat Google-Analytics imDezember 2017 entfernt.
* Das Webkoll Ergebnis für riot.im .
Mein Gesamteindruck war damals: Datenschutz steht nicht im Vordergrund.
Was ich sehr gut fand war dass einem direkt alle öffentlichen Chaträume vom eigenen Anbieter angezeigt werden. Gultsch zeigt sich nicht sehr interessiert an so einem Feature, es gäbe außer dem Kuketz-MUC und anderen technischen geprägten MUCs nicht viel zu entdecken. Ich sehe das anders, wenn es möglich wäre, dann würden die Nutzer schon dafür sorgen dass es was zu entdecken gibt. Anders wird es bei Matrix ja auch nicht sein.
Zu der Zeit hatte ich nur einen iOS Kontakt und ich dachte auch nicht dass ich heute immer noch warten würde.
Zum Thema Analytics in Riot möchte ich nun anmerken, dass zwar ‚Google Analytics‘ entfernt wurde, nun jedoch ‚Matomo’/’Piwik‘ an dessen Stelle getreten ist. Zudem neuerdings -mit dem letzten Update vom 22.02.18- nun es auch die Anwendung bei F-Droid getroffen hat
(siehe in der Beschreibung unter antifeatures), was mich vom Update abhält.
Nun, man kann in den Einstellungen von Riot einfach Piwik deaktivieren (opt-out). Nicht schön gelöst, aber es funktioniert.
Also ich finde Matomo wesentlich besser, da man es selbst hosten kann und Google damit keine Daten zur Verfügung gestellt werden. Und dass man als Betreiber einer Webseite ein Interesse daran hat, zu sehen, welche Seiten oft besucht werden und ein Tool für eine Verbesserung selbiger braucht, ist legitim.
Soweit ich weiß, strebt Matrix an, irgendwann mit XMPP zu federieren. Insofern gibt es für mich keinen Grund, zu Matrix zu wechseln. Ich bleibe einfach bei XMPP und warte bis Matrix die Federierung eingebaut hat.
XMPP hat für mich derzeit die besseren Clients: Gajim und Dino auf dem Desktop, profanity, mcabber uvam. für die Console, diverse Bots, Movim als Webclient – bei Matrix sehe ich diese Möglichkeiten nicht, es gibt praktisch nur den Webclient „Riot“. Es werden zwar auf der Webseite viele genannt, aber auf meinem OS (Debian) ist davon praktisch nichts verfügbar.
Auch die Server-Situation empfinde ich bei Matrix noch als unbefriedigend. synapse scheint offiziell nicht mehr unterstütz zu werden, aber der neue Server (offenbar in Go geschrieben, statt Python) ist wohl noch nicht ganz fertig. Übrigens ist „synapse“ unter Debian unstable und testing auch mit einem einfachen „sudo apt install matrix-synapse“ installierbar, man braucht also die „pip-Orgie“ nur unter Debian stable. Für XMPP sieht es besser aus: prosody wurde ja erwähnt, aber es gibt auch ejabberd, welches heutzutage auch nicht mehr so kompliziert für den Admin ist wie noch vor ein paar Jahren.
Und dann gibt es noch ein „politisches“ Problem, welches ich mit Matrix habe: Zwar sind Protokoll und Software frei und offen, aber trotzdem wird die ganze Sache von einer einzelnen Firma gesteuert. Bei XMPP ist es dagegen eine Community (XSF). Das gefällt mir persönlich einfach besser.
XMPP ist eher ein „Ökosystem“ mit einem gewissen Artenreichtum, wo aber auch mal ein Tierchen das andere frisst. Matrix ist eher eine „Monokultur“, alles schön sauber und ordentlich, aber kein Platz für Frösche und Lurche.
Sorry, aber mit dieser Aussage stehst du mit Sicherheit ziemlich alleine da. Es gibt auch für Matrix viele Clients und Bots abseits von Riot und fast alle sind keine Webanwendung. Für das versenden einer Nachreicht reicht sogar einfach die Konsole und Curl aus (sofern man bereits ein Access Token und einen Raum hat):
curl -XPOST -d '{"msgtype":"m.text", "body":"hello world"}' "https://matrix.domain.tld/_matrix/client/r0/rooms/ROOM_ID/send/m.room.message?access_token=ACCESS_TOKEN"Und ich möchte mal wissen, wie viele Leute die total veralteten Pakete aus dem Debian stable Zweig für Ihren XMPP-Server oder -Client nutzen. Man muss deshalb sowieso manuell nachhelfen und es kommt unter Umständen sogar zu einem viel höheren Arbeitsaufwand als bei einen simplen hantieren mit pip. Läuft der Server, reicht ein einziger kleiner Befehl mit pip aus und der Matrix-Server ist in Sekunden auf dem neuesten Stand! Zudem kommen noch viele weitere Vorteile in Verbindung mit Virtualenv (isolierte Python-Umgebung) hinzu, aber ich schweife vom Thema ab…
Synapse ist bis auf unbestimmte Zeit der offiziell unterstütze Server in den auch fleißig weiter investiert wird (Patches, Features, etc.). Dendrite (als Nachfolger) wird noch etwas Zeit benötigen, aber Synapse läuft mittlerweile gut – beim Server gibt es aktuell keinen dringenden Wechselgrund (ich kann jedenfalls keinen erkennen).
Diese Aussage/Meinung bzw. Behauptung kommt mir sehr bekannt gibt vor und gibt vor allem die Meinung von Herrn Gultsch wieder. Es ist schon bezeichnend, dass in jedem Artikel oder Blog über Matrix immer die selben halbgaren Argumente aus der Kiste geholt werden… Gerade die XSF hat in den letzten Jahren unglaublich viele XEPs entweder auslaufen lassen oder gar nicht erst offiziell aufgenommen bzw. einfach abgewiesen oder gar auflaufen lassen. Das empfinde ich nicht als eine Entscheidung der „Community“… Im Grunde ähneln sich Beide vom Ansatz her ziemlich stark, leider mit allen Vor- und Nachteilen.
Versuch das mal aus Entwicklersicht zu sehen. Ich denke dass das aus der Perspektive durchaus relevant ist.
Zu erstem Punkt hatte ich noch etwas vergessen:
* Der auch von dir kritisierte zentrale Identitätsspeicher. Mir wäre lieber gewesen das würde bei der Einrichtung nicht abgefragt, meinetwegen in den Kontoeinstellungen bei Bedarf. Damit klar ist: Das ist Optional. So ist man als Laie geneigt zu glauben das ist notwendig.
Norbert: Mein Aussage bzgl. Clients ist „auf meinem OS (Debian) ist davon praktisch nichts verfügbar.“ Welche Clients gibt es denn da? Meines Wissens weder einen GTK-basierten Client (ich nutze XFCE) noch einen Console-Client. Und an Debian hängen dann ja noch andere Distros, wie Ubuntu, Mint, Tails…
Bzgl. pip: Auf meine Rechner kommt nichts, was nicht ordentlich paketiert ist. Irgendwas mit pip oder „make install“ irgendwo hininstallieren ist ja nett um mal was auszuprobieren, aber ohne Integration in das Paketmanagement (=> Übersicht über jegliche auf dem System installierte Software, ordentliche Verwaltung der Abhängigkeiten, Upgrade mit einem einzigen Befehl für das System statt „ein einziger Befehl“ für jeweils eines von tausend Paketen) ist es nichts für mich. Ich installiere mir ja auch keine Firefox-Plugins von mozilla.biz, sondern nehme die Debian-Pakete wie es sich gehört.
Aber es macht ja nichts: Matrix hat ja angekündigt mit XMPP zu federieren, d.h. ich kann einfach bei XMPP bleiben und trotzdem bald mit Matrix-Usern kommunizieren, richtig?
Noch eine Ergänzung: Debian stable (mit backports!) hat die neuesten Versionen von prosody, prosody-modules, gajim und die diversen gajim-plugins. Kein Gefrickel erforderlich.
Es ist natürlich nicht der Fehler von Matrix, daß die XMPP-Packages bei Debian aktueller und vollständiger sind als die Matrix-Packages, aber es ist für mich einer von mehreren Gründen, warum ich derzeit Matrix nicht einsetzen kann oder will.
Gegenfrage zu deinem ersten Absatz: Welche aktuellen XMMP-Client und -Server (-Versionen) gibt es denn in Debian stable ohne Backports? Wohl keine und genau deshalb wird man nicht umhinkommen andere oder fremde Paketquellen einzubinden oder sich selbst Pakete aus dem aktuellen Quellcode zu erstellen. Oder gibst du dich mit uralten Client und Server Versionen bezüglich XMPP zufrieden? Mit fremden Paketquellen hätte ich doch arge Bauchschmerzen und dies käme auf (m)einem Server niemals in Frage. Und auch die Debian Backports kommen ohne jegliche Garantie und schlimmer noch ohne offizielle Unterstützung durch das Debian Security Team einher und sind auf eigenes Risiko zu benutzen (as-is basis). Außerdem findet man dort außer gajim, ejabberd und prosody auch nichts weiter bezüglich XMPP.
Mit pip installiert man nirgendwo einfach so etwas hin wenn man virtualenv einsetzt und es reicht ein einziger Befehl um ALLE involvierten Pakete und Abhängigkeiten (dependencies/requirements) aufzulisten und tatsächlich braucht es auch nur einen einzigen Befehl um ALLE Pakete aktuell zu halten. Pip ist schließlich ein Paketverwaltungsprogramm und ich persönlich sehe keinen Grund warum man es nicht neben APT oder anderen Paketverwaltungen einsetzen will oder kann.
Ohne Mithilfe aus dem XMPP-Lager wird daraus so schnell nichts werden. Und wenn ich mir manchmal die Kommentare durchlese – egal wo und zu welchem Artikel über Matrix – sehe ich diesbezüglich schwarz. Ich habe selten so einen Frust, ja sogar schon Hass auf etwas eigentlich Lobenswertes (in dieser schwierigen Zeit) gesehen. Und was am meisten schmerzt ist, dass die meisten Anfeindungen und Diffamierungen (vor allem Falschdarstellungen und Behauptungen) klar aus dem XMPP-Lager kommen. Man muss diesbezüglich nur mal kurz in einem der bekannten MUCs (z.b. für Conversations -> conversations@conference.siacs.eu oder anderen) unterwegs sein um schnell zu merken was dort Sache bzw. Sprache ist.
Norbert, meine Rechner haben ein Paketverwaltungsprogramm und ich will sicher nicht mehrere parallel einsetzen. Mit pip kann ich nicht mein System verwalten. Auch nicht mit npm, gem, cargo und was noch alles. Ist aber auch egal, ich habe ja schon geschrieben, daß die mangelnde Verfügbarkeit von Matrix-Software bei Debian nicht die Schuld von Matrix ist, sondern der Tatsache geschuldet, daß Debian eben noch nicht viel Matrix-Software paketiert hat. In zwei, drei Jahren sieht das sicherlich besser aus und dann habe ich einen für mich sehr relevanten Grund weniger, Matrix nicht zu nutzen. Aber vorher eben nicht.
Warum allerdings Matrix Hilfe aus dem „XMPP-Lager“ braucht um ihren angekündigten Plan zu realisieren mit XMPP zu federieren, ist mir nicht klar. Das Protokoll ist doch offen und ausführlich dokumentiert, die Software quelloffen. Matrix verspricht da leider mehr als es zu halten in der Lage ist.
Nach einer Weile Laufzeit allerdings deutlich ressourcenfressender als XMPP. Vor allem weil Matrix per default Messages auf dem Server speichert, was eine rassant wachsende Datenbank zur folge hat, sobald mal ein paar User Räumen mit ein paar hundert oder tausend Mitgliedern joint. Daraus folgt das das Teil im laufe der Zeit unglaublich träge wird.
Außerdem stört mich bei Matrix das die Clientsituation der von XMPP, was die Vielfalt angeht, gleicht. Es gibt Riot für alle Plattformen und Web, das wars dann aber auch schon, zumindest was vernünftige Clients an geht. Der Rest sind entweder Konsolenclients/erweiterungen oder Clients die entweder vom UI grottig sind oder nicht alle Features unterstützen. Selbst die UI von Riot ist nicht wirklich das Gelbe vom Ei, imo.
Soviel zu meiner Kritik an Matrix. Den Artikel finde ich aber sehr gut und lesenswert. Ich selber nutze auch Matrix, allerdings ist es für mich eine Art moderne IRC Variante, da ich es hauptsächlich für Gruppenkommunikation nutze.
Als Admin eines Servers kann ich aber auch deine Kritik gut nachvollziehen und teile sie teilweise sogar.
Mit der bei jeder „Installation“ (von Synapse) voreingestellten SQLite-Datenbank kann ich dies bestätigen. Damit sollte man definitiv nicht den riesigen Chaträumen (mit bis zu 13.000 Benutzern und 1000 involvierten Servern) auf matrix.org beitreten, sondern besser nur kleineren Räumen und/oder sich auf ein paar lokale Räume/Benutzer beschränken – selbst ein Raspberry Pi 3 kommt aktuell mit 20-30 lokalen Benutzern und ca. 300 Räumen samt SQLite-Datenbank noch sehr gut zurecht (hab ich selbst so laufen). Mit einer richtigen Datenbank wie PostgreSQL, einem modernen Prozessor und einer SSD ändert sich dies jedoch komplett. Damit hab ich aktuell gar keine Performance-Probleme mehr, auch nicht in mehreren größeren Räumen wie z.B. Matrix HQ. Einen guten/schnellen Überblick der öffentlich zugänglichen Räume auf matrix.org und aller beteiligten Server (ein Chatraum liegt nämlich auf allen beigetretenen Servern und nicht nur auf einem einzigen Server wie das bei einem XMPP-MUC der Fall ist – kann man sich unter: https://view.matrix.org/
…verschaffen. Möchte man momentan viele tausende Benutzer und Räume samt Federation gleichzeitig schultern, sollte man auf das noch experimentelle Skalieren via „workers“ zurückgreifen: https://github.com/matrix-org/synapse/blob/master/docs/workers.rst
Damit hab ich auch schon erfolgreich einen Server in Betrieb genommen (zumindest bisher).
Das Performance- und Wachtumsproblem hatte ich damals mit Postgres und das ganze lief auf ner physikalischen Maschine mit SSD. Das war der Grund wieso ich das ganze das dann wieder sein gelassen hab, aber vielleicht hat sich seitdem auch wieder einiges getan, denn das ist jetzt über ein Jahr her. Allerdings lassen mich da die Aussagen des Admins auf dessen Server ich gerade bin, eher dran zweifeln da er auch über eine zu große und immer weiter wachsende DB am fluchen ist, da es offenbar auch nach wie vor keine vernünftige Möglichkeit gibt diese von alten Daten zu bereinigen.
Das erklärt auch wieso die Datenbank so schnell wächst. Des Weiteren befeuert das nur wieder meinen Hauptkritikpunkt an Matrix, das einfach alles auf dem Server vorgehalten wird. Wie in dem Issue kann man schön sehen was das für Diskussionen mit sich bringt wenn es um das löschen von Nachrichten geht. Gewisse Admins sagen dann halt „Nö, das Flag ignorier ich, bei mir wird nichts gelöscht in dem Raum.“.
Vor ca. einem Jahr hatte das gesamte Netzwerk (Matrix) – ausgelöst durch einen Fehler in Synapse – einen so genannten „Meltdown“ zu verzeichnen, was leider über mehrere Wochen heftige Performance-Probleme zur Folge hatte (traf aber nur Systeme mit Federation). Eventuell war das genau der Zeitraum von dem du sprichst. Jedenfalls kann ich momentan keine Probleme mehr feststellen.
Es gibt zwar keine reine Löschfunktion für alle Events, da dies dem Design und dem Ursprungsgedanken von Matrix widersprechen würde, aber man kann per Admin APIs die Datenbank erheblich erleichtern bzw. deren Größe reduzieren (nach VACUUM) und auch Dateien können gelöscht werden. Genau genommen per Purge History API: https://github.com/matrix-org/synapse/blob/master/docs/admin_api/purge_history_api.rst sowie Purge Remote Media API: https://github.com/matrix-org/synapse/blob/master/docs/admin_api/purge_remote_media.rst
Damit ist es dem Server Admin möglich, nicht lokal erzeugte Events/Dateien (remote content) tatsächlich zu reduzieren. Zumindest so lange bis diese Inhalte durch einzelne Benutzer in nicht lokal begrenzten Räumen erneut von fremden Servern abgerufen werden (per „back pagination/backfill“). Es werden in diesem Szenario aber immer nur die Inhalte nachgeladen/übernommen, die auch tatsächlich angefordert wurden (also NICHT der gesamte Raum mit sämtlichen Daten in einem Rutsch etc.). Meine Datenbanken wachsen eigentlich moderat, selbst mein Testsystem mit weitläufiger Federation (auch mit sehr großen Räumen) hat nach über einem Jahr gerade mal 10 GB angehäuft. Mit dem oben genannten Verfahren konnte ich bei einem konservativen Test (gewählter Zeitpunkt bezüglich Purging relativ weit in der Vergangenheit liegend) die Größe um ca. 8 GB reduzieren, wobei ich aber keinen direkten Geschwindigkeitsvorteil vernommen habe. Ich denke auf einem „normal“ betriebenen Server stellt der Platzverbrauch der Datenbank/Dateien aktuell kein Problem dar. Mein Kritikpunkt daran ist, dass dieses Verfahren (Purging) momentan nicht besonders intuitiv oder automatisiert ist. Aber diesbezüglich wird es in Zukunft garantiert diverse Verbesserungen geben. Ich denke es ist ein unschätzbarer Vorteil, dass nicht lokal begrenzte Räume per Federation auf allen beteiligten Servern verfügbar sind (d.h. wenn es entsprechend Benutzer von fremden Servern darin gibt -> ansonsten natürlich nicht). So kann es nach einer Aufgabe/Abschaltung eines oder gar des ursprünglichen Servers einfach weitergehen und der Raum samt Inhalt ist dadurch nicht verloren bzw. besteht auf anderen Servern weiterhin. Vermeintliches „löschen“ von Nachrichten per „Redaction“ ist ein komplett anderes Thema, dein Link zeigt eigentlich nur die Konfusion einzelner Leute die wild alles durcheinander werfen (dies werde ich hier aber nicht aufschlüsseln können).
Danke für den Artikel.
Folgende Fragen wären da noch meinerseits:
Wird Video und Voice Telefonie unterstützt? Wenn ja, dann auch für Gruppen und wird das verschlüsselt übertragen?
Wie gut ist die Gruppenrechte Verwaltung. Lässt sich Discord mit Matrix (Riot) ersetzen?
Kann ein Matrix Server auch nur innerhalb der Domäne betrieben werden, also ist es für Firmen geeignet?
Auf die Fragen hier habe ich meine Antwort aber ich würde gerne Antworten von anderer Benutzer die Matrix schon länger verwenden und verstehen, bekommen. Gerne auch ein Verweis ins Forum. Danke
Ja. Jedenfalls haben mir User von anderen (auch nicht-matrix.org-)Servern das bestätigt. Mein TURN-Server scheint leider noch nicht so richtig rund zu laufen bzw. gibt es mit dem F-Droid-Client Probleme. Doskutiert wird das aktuell hier: https://github.com/vector-im/riot-android/issues/1744
Ich kenne Discord nicht. Hier mal eine Übersicht an Einstellungen aus einem Matrix-Raum:
Ich hatte es bei meiner Stud. Hilfskraftstelle kürzlich mal probiert. Dort ist die interne Domain jedoch eine .lan-Adresse, weswegen ich Probleme hatte, die selbst signierten Zertifikate auf den Clients als gültig aktiviert zu bekommen. Da darin ein „hausgemachtes“ Problem sehe, wüsste icht nicht, was sonst dagegen sprechen könnte, einen Matrix-Server als nur intern erreichbare Plattform zu betreiben (wenn Du das meintest).
Kuketz-Forum schaffe ich leider zeitlich nicht auch nocht. Hoffe, ich konnte weiterhelfen.
Wichtiges Thema mit einer interessanten Diskussion – Danke! Was mich als „Alt-Internetzler“ wirklich mal brennend interessieren würde wäre ein richtiger echter Vergleich und/oder klare Abgrenzung zum IRC (Internet-Relay-Chat). Das gab es schon vor 30 Jahren. Es gab private und Gruppenchats, es skalierte hervorragend, man konnte es – wie das Internet an sich – auch recht anonym nutzen, es funktionierte prima… Und ja, bis auf das es damals keine Smartphone-Clients gab weil es ja noch keine „smarten“ Telefone gab und natürlich auch Verschlüsselung kein besonders wichtiges Thema war: es funktionierte einfach! Und selbst die IRC-Server könnte man im Rückblick in gewisser weise als „federal“ bezeichnen. Sie bauten ihre Verbindungen untereinander bei Bedarf auf aber als User hatte man freie Auswahl sich auf einem „Anonymous“-Server irgendwo auf diesem Planeten zu konnekten um von dortaus zu chatten, sozusagen VPN 1.0. Wo oder was sind denn jetzt eigentlich die ganzen SuperbonusspitzenNEUE-Features die ein heutiger „moderner“ Chatclient wie Whatsapp, Signal, Telegram, Matrix (Riot), Conversations (XMPP) wirklich bietet?? Ist der einzige Mehrwert vielleicht die besseren Filterungsmöglichkeiten, das Whatsapp alle nutzen (ich nicht) oder doch nur die Ende-zu-Ende-Verschlüssselung… obwohl sich da wohl in der Zwischenzeit bei IRC auch so einiges getan haben soll. Für alle die IRC nicht kennen sollten und nicht zuordnen können worüber Opa hier aus dem Krieg berichtet – die Technik ist immerhin von 1988 – mal ein Link: https://de.wikipedia.org/wiki/Internet_Relay_Chat
Schade, das System hatte bisher nur eine Person hier in den Kommentaren ganz kurz erwähnt. Doch ich finde IRC – die Technik, die Geschichte dahinter und die gesammelten Erfahrungen (das ganze ist ja auch ein Protokoll) sollten auch Teil einer Diskussion über heutige Messenger sein um damit damals gewonnen Einsichten/Erkenntnisse einfließen zu lassen und letztendlich auch, um sicherzustellen, dass man die Räder nicht zwei- oder dreimal neu erfinden muss!
Ich habe IRC mal in einem Projekt benutzt (teilweise aus Thunderbird heraus, was wirklich toll war, teilweise mit, ich glaube, HexChat).
Was genervt hat/was die „SuperbonusspitzenNEUE-Features“ sind, die IRC nicht bietet/bot:
– keine offline-Nachrichten? (bedeutet also Protokollwechsel, wenn jemand nicht im IRC online ist)
– Drag&Drop für Dateien?
– Link-Vorschau? (gut, kann man vielleicht mit Bots lösen)
– Markdown-Formatierungsmöglichkeit von Texten? (ist vielleicht ein Client-Frage)
– ein Foto einer Projekt-Arbeit mit dem Smartphone direkt in den Projekt-Chat posten?
– AV-Konferenzfähigkeit? (gut, jetzt könnte ich in diesem Zusammenhang noch „-Spiegeleier braten?“ anführen, AV wird aber nunmal verlangt, und bevor mir die Leute mit der „Slack-Keule“ kommen, bin ich froh, dass Matrix auch soetwas bietet)
Ansonsten ist Matrix (wie auch Slack und Mattermost) interessanterweise durchaus ein Schritt darhin, was mit IRC schonmal erfunden (?) wurde. In der Usability liegen jedoch aus Sicht derer, die IRC nicht mehr kennen, Welten dazwischen.
IRC hat dazu durchaus einiges auf Lager…
Offline-Nachrichten: MemoServ, a memo service bot, is used to record and deliver messages to users who are currently offline. Zudem kann das auch per IRC-Bouncer, eine Art von Proxy, gelöst werden. Bouncer 1 – Bouncer 2. Der Datei-Austausch ist im IRC via DCC fest verankert und ein Drag&Drop-Feature ist deshalb nur eine Frage des richtigen Clients! Gleiches gilt für Formatierungsmöglichkeiten. Und Fotos vom Smartphone in den Projekt-Chat sollte auch problemlos gehen. In Richtung AV (Audio&Video) wurde IRC damals natürlich nicht entwickelt, doch es gibt heute immer noch einen Haufen Server und eine große Menge verschiedener Clients gibt, die fast alle Open Source sind und auch heute noch ziemlich viele Funktionen out-of-the-box unterstützen. Da wäre eine AV-Funktion nur ein weiterer Baustein.
@Robert, ich habe zugegebener Maßen keine Ahnung wie IRC Clients im mobilen Bereich funktionieren, aber 2016 hat der Hauptentwickler vom XMPP Client Converstions einmal einen Blog Beitrag geschrieben, in dem es auch darum geht wie der Batterieverbrauch der App durch Protokoll-Features verringert wird:
https://gultsch.de/xmpp_2016.html (Abschnitt „Battery drain“)
Ich fand Beitrag den sehr aufschlussreich und ich vermute, dass die IRC Clients diese Art der Optimierung bisher nicht einsetzen. Korrigiere mich gerne falls ich da falsch liege.
Was mich persönlich an Matrix stört, ist dass etwas neu erfunden wird was es schon gibt. Also wenn man sich die Features von XMPP und Matrix im Vergleich anschaut, dann hab ich nicht das Gefühl das hier irgendwas neues entsteht.
Aus meiner Sicht ist das was XMPP am meisten fehlt, eine gesunde Client Landschaft. Die wenigsten Clients unterstützen moderne Erweiterungen, was häufig dazu führt, dass XMPP als veraltetes Protokoll wahrgenommen wird. Tatsächlich ist es aber so, dass sich XMPP durchaus sehen lassen kann, wenn man einen modernen Client hat (z.B. Conversations). Nur aktuell scheinen mehr Leute daran interessiert einen Client für Matrix zu bauen, als einfach mal die XMPP Clients auf einen aktuellen Stand zu bringen.
Nur wer z.B. einen Modernen Desktop Client sucht, der soll mir Bescheid sagen wenn er einen findet, der auch „funktioniert“.
Bisher hab ich folgende ausprobiert:
– Gajim -> (kein Message Archive Management (XEP-0313), Chat Markers (XEP-0333))
– Pidgin -> (kein Message Archive Management (XEP-0313), Chat Markers (XEP-0333))
– Jitsi -> kein OMEMO
– Dino -> XMPP Features sind gut, aber kein Release, in den Entwicklerversionen zu viele Bugs und elementare Dinge wie ein System Tray Icon fehlen
Hallo Roland,
danke für den Beitrag. Ich bin nur Hobbyadmin und habe auch den „so einfach zu konfigurierenden“ Prosody probiert. Nach kurzer Zeit bin ich auf ejabberd umgestiegen. Vielleicht testest du den für dich auch mal. Nachrichtenverluste hatte ich bisher nur auf Prosody, besitze allerdings keine IOS Geräte zum Vergleich.
Grüße E
Danke Erik. Zumindest für einen freien TeamViewer-Ersatz via Jitsi werde ich wohl nochmal einen XMPP-Server aufsetzen und mir dann ejabberd anschauen.
Hallo Roland, hallo Mike. Kenne mich mit XMPP und Matrix und all der Technologie dahinter null aus, aber ich verstehe im Gegensatz zu all den „XMPP IT-Profis“ was Roland uns eigentlich sagen wollte. Und zwar, dass ein föderaler Messenger -wie das Email-System auch- für die 99% der Menschen konzipiert sein muss. Es ist wie mit den Behördenschreiben; den Juristen gefällt diese Sprache, dem normalen Menschen nicht. So ist es auch wahrscheinlich mit XMPP und Matrix; XMPP gefällt der 1% Elite, der Rest guckt in die Röhre.
Ih würde bei zukünftigen Entwicklungen auf jeden Fall IT-Laien hinzuziehen, damit man sein Produkt auf die Massentauglichkeit hin entwickelt. Dann könnte man sogar Geld verdienen und müsste nicht um Spenden betteln.
Danke für deinen Artikel Roland und wenn ich dich falsch verstanden habe, sieh es mir nicht nach, denn ich bin kein IT-Fachmann :)
„Konkurrenz-belebt-Geschäft“ hat vollkommen recht. Wer nicht sehr konsequent vom ahnungslosen Benutzer aus denkt, wird diesen auch mit seinen Lösungen und Produkten nicht erreichen. Wer mehr von der Technik aus denkt, bleibt mit seinen Lösungen immer in der Nerd-Nische. Für mich erklärt das den (relativen) Erfolg von Signal und Misserfolg von XMPP.
Ich verstehe nicht warum ich Matrix oder XMPP nutzen sollte die teilweise die Zentralisierung aufheben wenn es Briar gibt.
Briar benötigt keine zentrale Server, läuft by default über Tor, stellt by default die maximale mögliche Anonymität und bestmöglichen Datenschutz ein (wurde als Kritik bei den default settings des Servers genannt) usw.
Die einzige Kritik die vom Verfasser betreffend Briar genannt wurden sind „keine Bilder“.
Ich soll also damit ich Bilder verschicken sollte auf Tor verzichten und einen nicht unerheblichen Aufwand betreiben einen eigenen Server laufen zu lassen (App in F-Droid installieren VS kompletten Linux Server zuhause laufen lassen) nur damit ich Bilder in die Kommunikation einbinden kann?
Warum soll ich so sehr Bilder versenden wollen? Nur damit ich nicht aktualisierte CyanogenMod Smartphones in deren media-library exploiten kann?
Matrix macht auch nichts für die Tofu-Problematik. Dagegen eliminiert Briar die Trust-on-first-use-Problematik vollständig!
Ich sehe wirklich gar keinen Vorteil darin Matrix zu verwenden. Wenn ich schon einen zentralisierten Dienst haben möchte der as-easy-as-possible läuft, dann kann ich auch direkt Signal nehmen.
Briar ist meiner Meinung nach der einzige gute und Sinnvolle Messenger der ENDGÜLTIG alle Probleme im Bereich Datenschutz beseitigt.
Vollständig dezentral – check, vollständig freie Software – check, ausschließlich ende-zu-ende verschlüsselt – check, die eigene IP-Adresse bleibt vollständig verborgen – check, kein metadaten-leaking – check.
Hallo Anonymous,
danke für Deine Kritik, aber auch hier habe ich wieder das Gefühl, dass mein Artikel höchstens überflogen wurde. Keineswegens mangelt es bei Briar nur an der Möglichkeit, Bilder zu versenden.
1. Du kannst mir doch nicht ernsthaft erzählen, dass man Briar in der akt. Fassung Familie und Freund*innen vorsetzen kann… nicht, dass ich es nicht mal in einem kleinen Kreis versucht hätte: als nach 15min die Koppelung per QR-Code bei einem Interessenten immernoch nicht geklappt hat, war das System für den Interessenten „unten durch“ – wieviele Mittagspausen soll man denn opfern, damit ein Kontakt hinzugefügt werden kann? Soviel zu TOFU.
2. Lies nochmal meine Anforderungsmatrix: iOS-Client? Desktop-Client?
3. Bilder: ist ja schön und gut, wenn Du auf Bilder verzichten kannst, aber wenn wir auf diesem Usability-Niveau bleiben wollen, reicht auch „Silence“ für verschlüsselte SMS.
Selbst wenn ich das Problem über Upload-Links löse: meinem letzten Stand nach kann Briar ja nichtmal Links parsen (wahrscheinlich als Sicherheits-Feature). Aber soll ich ernsthaft eine Nachricht in einen Editor kopieren, um an den Link in einer Nachricht zu kommen? Wie soll ich das bitte meinen Eltern erklären?
4. Nochmal zu TOFU: es soll vorkommen, dass User Handys verlieren. Und dann? Den gesamten Freundeskreis abklappern, um sich neu TOFU-konform zu vernetzen?
Versteh mich nicht falsch: Briar ist selbst in der Beta ein erstklassiger Messenger – für einen sehr spezifischen Anwendungsfall (investigative Journalisten bspw.)! Dieser Anwendungsfall ist jedoch (jedenfalls aktuell) nicht „Alltagskommunikation mit Kolleg*innen, Freund*innen und Familie“. Wenn Briar aus der Beta raus ist, werde ich mir das Konzept gerne als Alltags-Messenger nochmal anschauen, sofern dann auch ein iOS-Client zur Verfügung steht, denn auch ich halte serverlose Konzepte für die beste Lösung für das eigentliche Ziel, zivilgesellschaftliche kontrollierbare IT-Strukturen aufzubauen.
Hatte den Beitrag schon gelesen, jedoch war dein Kritikpunkt bei Briar nicht Usability oder sonstige Punkte die du jetzt erst genannt hast, sondern „keine Bilder, Android-only“.
Sichere Messenger nutzen Leute die sich für deren Datenschutz interessieren. Und eben solchen kann man security-through-obscurity bei closed-source-systeme gut erklären und die nutzen dann auch kein iphone mehr.
Andere interessieren sich nicht mal dafür ein paar MB Speicher auf deren Smartphone zu belegen. CandyCrush ist denen wichtiger als sichere Kommunikation.
Und dein Punkt mit „Silence“ ist völlig unpassend, den Silence ermöglicht es nicht ohne personenbezogene Daten (Rufnummer) TOFU-Korrekt kommunizieren zu können. Außerdem leakt es extrem deutlich Metadaten, da der ISP weiß wer mit wem kommunizierenden.
Briar ist nun mal meiner Meinung nach die endgültige Lösung was Sicherheit angeht. Auch ist der „Aufwand“ bei Briar nun mal keinen Server einrichten, warten usw. zu müssen sehr viel wert. Du kannst ja nicht erwarten, dass bekannte von dir einen Server einrichten. Dann aber wächst immer weiter die Zentralisierung(kennen wir von der Kritik zum ccc-xmpp Server). Und wenn es ohne Server auch nur irgendwie geht, dann ist das die beste dezentrale Lösung.
Du kannst dir noch das tox-over-tor https://wiki.tox.chat/users/tox_over_tor_tot ansehen. Erfüllt ähnlich (fehlenden TOFU-zwang – kann man gut oder schlecht finden) vollständig die endgültige messenger-lösung die alles bezüglich sicherheit beinhaltet. Dafür gibt es dann auch deinen gewünschten ios client – https://antidote.im/ . Ich erkläre dennoch viel lieber den Leuten denen Sicherheit interessiert das https://de.m.wikipedia.org/wiki/Kerckhoffs%E2%80%99_Prinzip von Jahr 1883 statt mit einer App denen zu ermöglichen weiterhin ein „Gefühl“ der Sicherheit aufrecht zu erhalten welches nicht nachprüfbar ist (reproduzierbare builds).
…wobei Du dich zunächst nur auf „keine Bilder“ bezogen hattest. Das Problem, keine Kontakte hinzufügen zu können, trat nicht immer auf, aber zu oft, ist daher nicht repräsentativ und auch im Zuge meiner Anforderungsmatrix nur ein Tropfen auf den heißen Stein. Aber wie dem auch sei: „keine Bilder“ und „Android only“ reicht doch bei ernsthafter Betrachtung schon, dass Briar aktuell keine WhatsApp-Alternative ist und sich damit für den Alltagseinsatz bei Freund*innen und Familie nicht eignet (schon allein, weil der iOS-Client fehlt – und ich werde nicht den Fehler begehen, zu versuchen, jemanden zu einem Messenger-Wechsel und zu einem System-Wechsel zu überzeugen).
Und was der Verlust des Smartphones für den Wiederaufbau der Kontaktliste bedeutet, will ich mir gar nicht erst vorstellen – vor allem dann nicht, wenn Teile der Familie auf einem anderen Kontinent leben. Oder aber die betroffenen User sie lassen sich die Kontakte vermitteln und verzichten darauf, die Kontakte neu zu scannen – dann haut aber das Sicherheitskonzept von Briar nicht mehr so ganz hin.
Sicherheitstechnisch hast Du recht, in Bezug auf Usability ist es aber nunmal der Stand, den wir zuletzt mit SMS hatten (und das war der Punkt, den ich meinte).
Unterschreibe ich. Aber wie gesagt: leider zu viele Probleme für den Alltag, siehe oben.
Aber ich kann erwarten, dass „Bekannte von mir“ einen Messenger nutzen, den es nur für Android gibt, der keine Medien-Dateien übertragen kann (oder will) und nicht erlaubt/sicherheitstechnisch nicht erlauben will, die Kontaktliste irgendwie zu sichern?
Danke. Bei meinem letzten TOX-Test unter Android war der Akku nach gefühlt 10min weg. Aber wie gesagt: danke, behalte ich auf dem Schirm.
…verstehe ich nicht ganz: hatte ich so argumentiert?
Anyway: Du hast ja mit Deinen Kommentaren schon mehr erreicht als ich mit meinem Gast-Beitrag: Empfehlungsecke: Briar unter Messenger hinzugefügt – Glückwunsch! :)
Die Beschreibung von Mike ist doch eine wunderbare Zusammenfassung, in der sich unsere Positionen beide wiederfinden.
Du schriebst, dass du den letzten Absatz nicht ganz verstanden hast.
Der Kontext ist wohl nicht klar genug von mir genannt worden.
Ich erkläre Leute die ein iPhone (closed source, Sicherheit somit als „black box“ an zu sehen, verstoß gegen Grundlagen von 1883) lieber den Grund warum sie erst mal eine nachprüfbare Basis brauchen wenn die auch nur im entferntesten daran denken „sicher“ zu kommunizieren. Den diese mit dem genanntem iOS tox client ein Gefühl zu vermitteln sie wären jetzt sicher ist einfach nur falsch. Apple speichert jetzt die private keys zur icloud nicht nur in den USA sondern auch in China. Ich rede lieber mit den Menschen darüber statt den irgendetwas für diese miserable Plattform zu empfehlen/nennen wenn sie sich für Sicherheit interessieren. Den sonst haben die eh kein Interesse irgend einen anderen Messenger zu installieren.
Und wenn dein gerät zu schnell leer wird mit tox (hat sich vielleicht bei dir nun gebessert), könntest du LineageOS 15.1 auf dieses Gerät portieren: https://www.teltarif.de/energizer-power-max-p16k-pro-hat-16000/news/71791.html
Lieber ein „Klopper“ in der Hosentasche als auf Sicherheit zu verzichten.
PS: Ich sehne mich so sehr nach freies Baseband. Leider ist das OpenMoko immer noch das einzige Smartphone auf diesen Planeten welches Open-Hardware und vollständig OpenSource (incl Baseband, Bootloader, …) ist. Ist jetzt aber ein anderes Thema und unabhängig der Messenger.
Aufpassen sollte jeder Matrix User beim Upload von Dateien und Avataren.
Zusätzlich zur matrix content id wird in den entsprechenden Tabellen in Datenbank auch der original Dateiname gespeichert (z.b. in der Tabelle local_media_repository). User die z.b. mit einem Pseudonym unterwegs sind können so unbewusst Informationen über sich verraten.
Tritt man einem Raum bei der auf einem andern Homeserver gehosted wird laden die Daten natürlich auch dort. Sind sie einmal im Netzwerk werden sie dort sehr lange verbleiben, wenn nicht sogar für immer.
Exif Daten werden vor dem Upload auch nicht bereinigt und können z.b. geolocation Daten beinhalten.