Auf Mastodon wurde am Freitag vor unserem LUKi-Treffen die Frage nach Alternativen zu WhatsApp gestellt. Konkreter geht es um XMPP oder Matrix als Messenger, die die Anforderungen nach freier Software und dezentralen Systemen erfüllen.
Wenn es nur um Ersatz für den Austausch von Textnachrichten zwischen Mobilgeräten geht, erfüllen vermutlich beide Systeme die wichtigsten Anforderungen. Beide Systeme haben aber ihre Macken und sind nicht uneingeschränkt empfehlenswert.
Hier kann es nur um meine persönlichen Erfahrungen mit Messengern gehen. Sie sind selbstverständlich subjektiv durch meine Anforderungen und Vorlieben gefärbt.
Meine Anforderungen
- Nachrichten sollen sofort zugestellt werden, wenn ich online bin.
- Nachrichten, die geschrieben wurden, während ich offline war, sollen zugestellt werden, sobald ich wieder online gehe.
- Es soll Gruppenchats geben.
- Transportverschlüsselung bei der Übertragung im Netzwerk
- Nachrichtenhistorie
- Clients für den Desktop
- Nutzung desselben Accounts auf mehreren Geräten gleichzeitig und im Wechsel
Anforderungen aus Sicht des Administrators:
- Der Server soll aus der Sicht des Systemadministrators schnell und sauber installierbar und konfigurierbar sein. Die Konfiguration soll gut dokumentiert und verständlich sein.
- Server soll sparsam mit den Ressourcen CPU und Memory umgehen.
- Die Server-Dienste soll nach Betriebsunterbrechungen ohne Zutun des Administrators sauber wieder in Betrieb gehen.
Weniger wichtige Anforderungen sind für mich:
- Push-Benachrichtigungen beim Eintreffen einer Nachricht auf Mobilgeräten
- Ende-zu-Ende Verschlüsselung
XMPP und Conversations auf Mobilgeräten
Ich bin optimistisch, dass der Einsatz von Conversations auf Android-Mobilgeräten in Kombination mit einem sauber konfigurierten Server ein guter Ersatz zur WhatsApp-Nutzung für Jedermann und Jedefrau ist. Die Serverfunktionen lassen sich mit den Werkzeugen, die Daniel Gultsch zur Verfügung stellt, überprüfen und bei Abweichungen gibt es Konfigurationsempfehlungen. Ich habe aber keine große Erfahrung mit Conversations für Normalanwendende. Eine Anleitung für Einsteiger gibt es im Kuketz-Blog als PDF unter einer Creative-Commons-Lizenz (cc by-sa).
Für Mobilgeräte mit iOS müssen die Anwender.innen auf ChatSecure als App ausweichen. Ich habe mit iOS keine Erfahrung und höre von Problemen, die mit dieser App auftreten können.
Matrix und Riot
Ein Matrix-Server ist schnell aufgesetzt. Bei meinen Versuchen, die einige Monate zurückliegen, war der Server nicht so konfigurierbar, wie ich es mir vorgestellt hatte. Es hat nicht so funktioniert, wie es meiner Meinung nach funktionieren sollte. Dokumentation dazu habe ich keine gefunden. Der Matrix-Server ist im Vergleich zu XMPP-Servern sehr ressourcenhungrig. XMPP-Server sind im Betrieb wesentlich angenehmer zu administrieren.
Privatsphäre und Sicherheit waren bei der Entwicklung der Matrix-Software zumindest in der Vergangenheit keine wichtigen Implementierungsziele. Dafür gibt es mehrere Hinweise: Google-Analytics in der Client-Software, der zentrale Identity-Server, der in den Clients vorbelegt ist etc. Ich habe die Hoffnung, dass sich das Bewusstsein der Entwickler an dieser Stelle geändert hat.
Beim aktuell verfügbaren Matrix-Server handelt es sich um eine Art von Prototyp. Eine Neuentwicklung in der Programmiersprache “Go” soll den Ressourcenhunger begrenzen. Auch die Implementierung der Ende-zu-Ende-Verschlüsselung hat noch Beta-Status. Auf jeden Fall hat Matrix Potential. Ich verhalte mich an der Stelle abwartend.
Riot als Client hat den Vorteil, dass es auf allen Plattformen verfügbar ist. Aber mir gefällt die Anwendung nicht besonders gut. Auf Mobilgeräten könnte ich damit leben, auf dem Desktop finde ich es eher hässlich und unübersichtlich.
Meine Empfehlung
Die Schlussfolgerung aus diesem Artikel kann nur sein: Es gibt keine eindeutige Empfehlung.
Als Alternative zu WhatsApp auf dem Handy würde ich für Privatanwender Threema und Conversations nennen. Im besten Fall nutzt man XMPP auf einem Server mit der eigenen Domain. Dazu gibt es in Deutschland viele Hosting-Angebote von kleineren privaten Hostern oder von Kooperativen. Insbesondere nenne ich hier das Angebot des Conversations-Entwicklers Daniel Gultsch.
Für Organisationen, die eine eigene Infrastruktur betreiben wollen, empfehle ich Mattermost oder den eigenen XMPP-Server.
Mit dem produktiven Einsatz von Matrix würde ich persönlich noch warten.
XMPP in einer heterogenen Umgebung
Die Stärke von XMPP liegt in der Verfügbarkeit von vielen verschiedenen Server- und Client-Implementierungen. Die Grundfunktionen sind über alle Plattformen hinweg gegeben. 1:1-Chats ohne Ende-zu-Ende-Verschlüsselung funktionieren immer zwischen allen Plattformen.
Diese Vielfalt und die regelmäßige Erweiterung der Protokolle um weitere Funktionen führen leider immer wieder zu Kompatibilitätsproblemen. Dies führt dazu, dass viele XMPP nicht für Jedermann und Jedefrau empfehlen. Wenn XMPP aber reiner WhatsApp-Ersatz auf dem Handy sein soll: Siehe oben bei “Conversations”.
Chat in einer geschlossenen Nutzergruppe
Wenn alle Nutzerinnen und Nutzer zu einer Organisation gehören, kann man auf die Anforderung der Dezentralität der Server und Ende-zu-Ende Verschlüsselung verzichten. Es gibt nur einen Server unter der Kontrolle der gemeinsamen Organisation.
Für dieses Szenarium haben wir im LUKi e.V. gute Erfahrungen mit Mattermost gemacht. Mattermost ist eine freie Software, die als Alternative zu Cloud-Diensten wie zum Beispiel “Slack” positioniert wird. Unser Mattermost-Server läuft seit mehreren Jahren problemlos und ressourcenschonend. Es gibt Apps für Mobilgeräte und für den Desktop. Die Nachrichtenhistorie ist auf dem Server verfügbar. Push-Benachrichtigungen sind bei uns allerdings nicht implementiert.
Threema als Closed-Source-Alternative
Threema ist die einzige Messenger-App unter den bekannten Apps aus den Appstores, die ich empfehlen würde. Das Geschäftsmodell des Anbieters beruht auf moderaten Nutzergebühren. Als Privatanwender.in bezahlt man
einmalig für den Kauf der App.
Threema ist der einzige mir bekannte Messenger, bei dem es möglich ist das Hochladen der Kontakte aus dem Adressbuch vor der ersten Nutzung zu deaktivieren. Das ist Voraussetzung für eine datenschutzkonforme Nutzung des Messengers. Alle anderen mir bekannten Apps (ausser den oben beschriebenen) setzen in den Nutzungsbedingungen voraus, dass alle Inhalte des Adressbuchs im Mobilgerät auf die Server des Anbieters hochgeladen werden dürfen. Die Zustimmung aller Kontakte hat meines Wissens nie ein Nutzer eines Messengers eingeholt.
Lieber Peter,
danke für Deinen Artikel zur immer wieder spannenden Messenger-Debatte.
Da Du extra darauf hinweist: Subjektiv sind entsprechende Artikel immer irgendwie, die Frage ist vielmehr, ob die Argumentation im Kontext schlüssig ist und die behandelte Problematik vorausschauend genug behandelt wurde. Diesbezüglich kann ich nicht anders, als einige Deiner Punkte zu kritisieren, was ich mir deswegen erlaube, weil Dein Artikel, zumindest ist das mein persönlicher Eindruck, viele Argumente zur Problematik, die vielfach über die Mailingliste gingen, nicht berücksichtigt – was natürlich keine Voraussetzung dafür ist, hier Artikel zu veröffentlichen, aber vielleicht meine nachfolgende Kritik verständlicher macht.
Im Einzelnen:
Ja, die Dokumentation für Matrix-Synapse könnte besser sein, das gilt aber genauso für XMPP-Prosody, der als leicht aufzusetzender XMPP-Serverdienst gilt. Bei Prosody hatte ich jedoch auch nach etlichen Wochen der Doku-Recherche, zum Beispiel zur Frage, welche (Beta-)XEP ich noch bräuchte, um bereitzustellen, immernoch keine sauber funktionierende WhatsApp-Alterantive. Mit Synapse war die Sache an einem Nachmittag erledigt. Besonders für Hobby-Admins halte ich deswegen Matrix-Synapse, auch aufgrund des plattformübergreifenden Referenz-Clients (sodass man auch als Android-User einem iOS-User helfen kann, weil die Oberfläche die selbe ist), für die wesentlich bessere Lösung (gerade weil es Synapse kaum etwas nachkonfiguriert werden muss). Ausführlicher schildere ich meine Erfahrungen dazu bei Interesse unter https://www.kuketz-blog.de/messenger-matrix-das-xmpp-fuer-hobby-admins/ .
In der Debatte “XMPP VS Matrix” scheinen mir Admins immer so zu tun, als hätten Sie nicht mehr als einen Raspberry Pi zur Verfügung. Und selbst wenn das der Fall wäre: Bei mir liefen mehrere Monate Prosody, Synapse und weitere Dienste (u. A. Seafile) für Freunde und Familie (ca. 30 User) *parallel* stabil auf einem Cubietruck (der zwar doppelt soviel RAM hat wie ein RPi3, dafür aber auch nur halb so viele CPU-Cores).
Problematisch für den Arbeitsspeicher werden bei Matrix nur Räume mit mehreren tausend Mitgliedern – diese sind aber faktisch eh nur Machbarkeitsdemonstrationen und in der Praxis kaum nutzbar, wenn nur ein Bruchteil mal beschließt, in normaler Geschwindigkeit etwas zu posten. Vorsorglich begrenzt man serverseitig den RAM-Verbrauch bspw. über systemd, sodass sich der Server auch bei versehentlichem Beitritt in solche Räume nicht “verschlucken” kann.
Was genau heißt das? Ein auf Sicherheit bedachter Admin hat die Daten seiner User auf verschlüsselten Festplatten und muss diese bei einem Server-Neustart manuell entschlüsslen, bevor die davon abhängigen Server-Dienste staten können.
Ansonsten finde ich die Anforderungen, würden sie nicht am Ende einen eigenen Server implizieren, wenig spezifisch, da diese von so gut wie jedem aktuellen Messenger, egal ob FLOSS oder proprietär, erfüllt werden. Was die client-seitigen Anforderungen betrifft könnte ich mit dieser Anforderungsmatrix als “Advocatus Diaboli” sagen: Super, dann kann ich ja bei WhatsApp bleiben.
Was mir, abgesehen von der expliziten Forderung nach freien, föderalen Netzen ohne “Handy-Zwang”, völlig fehlt ist die AV-Telefonie: Wir leben in einer globalisierten Welt und Familien mit internationalen Verwandschaftsbeziehungen sind keine Seltenheit mehr. Eine WA-Alternative, die nicht vernünftig AV-Telefonie bereitstellt, ist (leider!) keine WA-Alternative.
Selbst wenn man nur mit Conversations unterwegs ist und sich dadurch auf Android beschränkt (und iOS-User damit ausschließt), ist dieser Optimismus aus meiner Erfahrung heraus wenig begründet. Ich hatte mich immer gewundert, warum es zu nicht reproduzierbarem Nachrichtenverlust unter XMPP kam und dachte, es läge an meinem Prosody. Später stellte sich heraus, dass es an einem Bugu in Conversations lag, wie ich später in einem Gespräch mit einigen XMPP-Admins erfuhr. Das Vertrauen in XMPP war jedenfalls während meines mehrmonatigen Testzeitraums völlig dahin (meine Test-User fingen an, mir SMS zu schicken, weil sie sich nie sicher waren, ob die Nachrichten tatsächlich ankamen oder nicht). Mit Matrix hatte ich nicht eine einzige verlorene Nachricht bisher.
Was den Anspruch an Hochverfügbarkeit selbst gehosteter Services betrifft bleibt im Artikel leider auch völlig unerwähnt, dass Matrix die Chat-Räume über alle beteiligten Server synchronisiert, was in Bezug auf die Verfügbarkeit derselben folgenden Vorteil gegenüber XMPP bedeutet: Hoste ich auf einem XMPP-Server einen Chat-Raum/MultiUserChannel/MUC und geht mein Server down kann der Chat-Raum, auch wenn dort die Mehrzahl der User keinen Account auf *meinem* Server hat, nicht mehr schreiben. Bei Matrix wären von der Downtime in so einem Chat-Raum nur diejenigen betroffen, die ihren Account auf *meinem* Server haben, alle anderen Teilnehmer*innen können munter weiter schreiben und merken von der Downtime rein gar nichts. Das ist in meinen Augen ein wirklich geniales Feature des Matrix-Protokolls, das viel zu wenig erwähnt wird, aber gewaltig Druck aus dem Kessel nimmt, wenn man als Admin eines kleinen Heim-Servers Teil eines föderalen Server-Verbundes ist, der so insgesamt “hochverfügbar” bleibt.
Und genau an der Stelle hört der Spaß mit XMPP leider auf, weil ChatSecure, zumindest in meinem Testzeitraum, eine Katastrophe war (nichtmal das Erstellen von Gruppen war möglich, das Beitreten zu bestehden MUCs reine Glückssache). Leider kann man von den Wechselwilligen nicht auch noch verlangen, die Plattform zu wechseln.
Diese Darstellung stimmt so schon lange nicht mehr und vergisst wichtige Aspekte:
1. Google-Analytics wurde schon vor langer Zeit vollständig auf Piwik umgestellt (nciht nur, was die Clients beitrifft, sondern auch die Website matrix.org).
2. Das Sammeln von Telemetriedaten in Riot wurde ebenfalls schon vor langer Zeit vollständig auf Opt-In umgestellt.
3. Der Identity-Server wird ausschließlich dann genutzt, wenn man zusätzlich zur Matrix-ID Telefonnummer und/oder Emailadresse angibt, um auch über diese gefunden werden zu können.
4. Der Identity-Server ist selbst in den Augen der Matrix-Entwickler nur eine schlechte Übergangslösung, siehe im Interview: https://www.golem.de/news/echtzeitkommunikation-ausprobiert-willkommen-in-der-matrix-1703-126197.html – davon abgesehen: Den meisten Usern ist es doch herzlich egal, ob ihre Handynummer oder Emailadresse irgendwo rumgeistert. Wichtig ist doch, dass Matrix/Riot den datenschutzbewussten Usern die vollständige Kontrolle darüber lässt, wie sie gefunden werden wollen.
Was genau soll den Leser*innen damit gesagt werden?
Der aktuelle Matrix-Server “Synapse” ist der Matrix-Referenz-Server und wird es auch noch eine ganze Weile bleiben, bis der Nachfolger “Dendrite” soweit ist. Auch das offizielle Hosting-Angebot von Matrix ( https://www.modular.im/ ) baut auf Synapse auf. Der Begriff “Prototyp” suggeriert hier, “Synapse” sei etwas “Halbgares”, was definitiv nicht der Fall ist. “Synapse” läuft überaus stabil und stellt einen zuverlässigen State-of-the-art-(Kollaborations-)Messengerdienst bereit.
Hier wäre interessant, was genau Du im Vergleich unübersichtlich findest und inwiefern der Riot-Desktop-Client im Aufbau unübersichtlicher ist als bspw. Gajim für XMPP. In beiden Fällen hat man links eine Kontaktliste, rechts ein Chatfenster, darunter ein Eingabefenster. Solnage die Buttons dort sind wo man sie erwartet kann und das Design halbwegs so gestaltet ist, dass ein Client ansatzweise barrierefrei genutzt werden kann (die Farben also bspw. nicht “hellgrauf” auf “dunkelgrau” sind), ist es in meinen Augen absolut zweitraning, ob ein Client den “90er-Tabellenkalkulations-Charme” versprüht wie es bspw. bei Gajim der Fall ist oder “viele bunte Kullern” hat wie Riot.
Um den Bogen zu meiner Einleitung zu spannen (“Argumentation im Kontext”): Ich verstehe, da Threema bei LUKi immer wieder empfohlen wird, nach wie vor nicht, wie im Kontext eines Vereins wie LUKi ein durch und durch proprietäres Messenger-System wie Threema empfohlen werden kann. Was zivilgesellschaftliche Kontrolle und Autonomie betrifft, macht Threema nichts besser als WhatsApp (und wer darauf vertraut, was in den AGB versprochen wird, kann auch darauf vertrauen, dass die DSGVO vor Facebooks und damit auch vor WhatsApps Interessen schützt – plausible kontrollieren (lassen) kann es in beiden Fällen niemand).
“Im besten Fall” für wen genau? Mit XMPP hätte ich meine internationale Verwandtschaft nicht aus den propr. Netzwerken herausbekommen, weil es für XMPP keine vermittelbare AV-Telefoniemöglichkeit gibt (nein, auch nicht mit Jitsi/Jisti-Meet und auch nicht mit einem extra bereitgestellt Mumble-Server – solche Konzepte sind für eine Generation, die nur WA kennt, nicht vermittelbar, selbst wenn man es mehrmals erklärt).
Auch hier kann ich nicht nachvollziehen, warum LUKi immer wieder Mattermost im kirchlichen Kontext empfiehlt. Was haben denn Gemeinden davon, wenn sie sich eigene “Walled Gardens” bauen und Gemeinde A dann irgendwann auch mal mit Gemeinde B kommunizieren will, die auch einen Mattermost-Server betreibt? An dieser Stelle löst Mattermost das eigentliche Problem, freie, *föderale* Netze aufzubauen, überhaupt nicht, sodass für die gemeindeübergreifende Kommunikation dann doch wieder viele Gemeinden auf ein übergeordnetes System zugreifen müssten (womit der Aspekt der IT-Autonomie dahin ist) oder (via “Schatten-IT”) auf die Systeme zurückgreifen, die man eigentlich überwinden wollte. Das wäre auch gegenüber XMPP ein Rückschritt.
Bei XMPP besteht nach wie vor das Problem, dass es aktuell keinen Client gibt, der aktuelle Kollaborations-Anforderungen auch nur einigermaßen erfüllt. Solange es für XMPP keinen plattformübergreifenden Client gibt, der AV-Telefonie ermöglicht, wird man damit nicht erolgreich gegen WA und/oder Slack (das ja noch nichtmal AV-Telefonie kann, aber wunderbare Kollaborations-Features mitbringt) vorgehen können. Auch, was die Kollaborations-Features betrifft, ist Matrix/Riot aktuell die einzige Alternative, die einem modernen Anforderungskatalog gerecht wird und dennoch freie, föderale Netze fördert, wodurch, wieder in Rekurs zu meiner Einleitung, die “behandelte Problematik vorausschauend” genug behandelt werden kann.
Davon abgesehen:
Keine IT, die einigermaßen effizient arbeiten muss/will, wird sich freiwillig auf das Experiment einlassen, für verschiedene Clients Support leisten zu müssen. Unter diesem Aspekt ist “Client-Vielfalt” für jede (in der Regel unterbesetzte) IT eher ein “Horror”. Das gilt auch für Heim-Admins, die selten mehrere OS-Plattformen im Einsatz haben. Hier war es für mich der Horror, für den XMPP-iOS-Support extra ein iPad ausleihen zu müssen, um die gemeldeten Probleme meiner XMPP-User nachvollziehen zu können.
Desweiteren:
Ich stimme Dir zu, dass “Ende-zu-Ende-Verschlüsselung” eine untergeordnete Rolle spielen muss, aber auch dies muss zumindest ansatzweise begründet werden (und eine Begründung dafür konnte ich Deinem Artikel nicht entnehmen).
Kurzum: Wer gute Verschlüsselung will, bekommt sie bei WhatsApp seit WhatsApp die Verschlüsselungstechnik von Signal implementiert hat, weswegen auch ich nicht mehr für Ende-zu-Ende-Verschlüsselung argumentiere, da uns diese rein gar nichts bringt, wenn wir als Zivilgesellschaft nicht auch die zugrundeliegenden Kommunikationsnetzwerke in unserer Hand haben (denn Verschlüsselung bringt einem gar nichts, wenn ein zentralisierter Dienst abgeschaltet wird, was im Zuge “zivilen Ungehorsams” bspw. bei den WM-Protesten Brasilien bereits vorkam).
Dennoch: Gerade im Kontext von kirchlicher Arbeit sollte Ende-zu-Ende-Verschlüsselung für die digitale Seelsorge gegeben sein. Auch hier bietet Riot einen denkbar niedrigschwelligen Einstieg, weil Seelsorger*innen durch die plattformübergreifende Verfügbarkeit wunderbar Support leisten können, dank Riot-*Web*App sogar im Notfall ohne eine Installation seitens der Hilfesuchenden.
Hier wäre für die Leser interessant, *warum* dies so ist: Derzeit wird noch darüber beraten, wie die Übertragung von privaten Schlüsseln bei wechselnden Geräten so geregelt werden soll, dass sie auch für User, die noch nie auf einer Kryptoparty waren, nicht zur Herausforderung wird. In verschlüsselten Chat-Räumen mit mehr als 2 Usern bringt es Ende-zu-Ende-Verschlüsselung prinzipbedingt mit sich, dass bei einem Gerätewechsels bei nur einem der User alle anderen (oft nervend) gewarnt werden, dass “User X” ein neues Gerät und damit auch ein neues Schlüsselpaar hat, das verifiziert werden sollte.
Und was genau gibt Dir bei einer propr. Software die Gewisstheit, dass die App hält, was sie verspricht?
Desweiteren fragt doch jedes halbwegs aktuelle Android vor einem Zugriff einer App auf das Adressbuch, ob dieser zugelassen werden soll.
Ist eine Lifetime-Lizenz für ~1€ wirklich ein plausibles Geschäftsmodell? Wie will man als Unternehmen denn so langfristig den Support sicherstellen?
Abschließend:
Davon abgesehen, dass Du aus meiner Sicht recht eindeutig Conversations und Threema empfiehlst, lassen sich mit Deiner Anforderungsmatrix nur schwierig Empfehlungen formulieren, die zugleich die Systeme, die wir aus LUKi-Perspektive ablehnen (sollten), ausschließen. Daher hier nochmals mein schon öfter über die Mailingliste präsentierter Vorschlag für eine Messenger-Anforderungsmatrix, die sowohl den Prinzipien von LUKi gerecht wird als auch die Erwartungen im Kontext von WA/Slack-Features bedient:
1. zivilgesellschaftliche Kontrollmöglichkeit durch Freie Software für Clients und Server
2. kein “walled garden”, sondern zivilgesellschaftliche Autonomie durch föderalen Server-Betrieb (wie bei E-Mail intuitiv und bekannt)
3. Clients mit graphischer Oberfläche für Android, GNU/Linux, MacOS/iOS, Windows (bedeutet auch: Messengers muss auch ohne Smartphone nutzbar sein)
4. Android-App muss über F-Droid verfügbar sein oder sich selbst updaten können
5. Unabhängigkeit von Mobilfunkverträgen (daher: eigenständige Zugangsdaten (Username und Passwort) ohne Bindung dieser Zugangsdaten an Telefonnummer, E-Mail-Adresse oder sonstige weitere Daten (bedeutet auch: Nutzung muss ohne Abgleich des lokalen Adressbuchs sinnvoll möglich sein)
6. verlässlicher Nachrichtentransfer und zuverlässige Fehlermeldung bei Unzustellbarkeit von Nachrichten, Bildern und Videos
7. Möglichkeit zur Ende-zu-Ende-Verschlüsslung für Einzel- und Gruppenchats
8. Audio/Video-Chat möglich
9. Nutzung auch als Gast möglich
Der Liste könnte man entsprechend Deines Artikels nun als Punkt 10 hinzufügen:
10. Die Clients müssen *von sich aus* Funktionen mitbringen, den Abgleich mit dem Adressbuch zu unterbinden.
Ebenso für Matrix, Übersichten dafür sind bspw.:
– https://www.hello-matrix.net/public_servers.php
– https://matrixstats.org/homeservers/
(- https://www.modular.im/)
Ob diese in Deutschland stehen, ist meiner Meinung nach nach den Snowden-Enthüllungen kein Kriterium mehr (jedenfalls keines, was aus datenschutzrechtlicher Perspektive tatsächlich dazu taugt, Menschen zu schützen). Auch fernab der Vermutung, dass die Interessen ausländischer Geheimdienste fest in der deutschen Gesetzgebung verankert sind (vgl. “Land unter Kontrolle : Die GEschichte der Überwachung der BRD” unter http://www.3sat.de/mediathek/?mode=play&obj=41243 ) scheint die Lobby der IT-Großkonzerne auch auf EU-Ebene so stark, dass ich auch auf DSGVO nur insofern etwas gebe, dass ich sie einhalten muss, mir aber von ihr keinerlei Schutz im digitalen Raum erhoffe, da auch sie von besagten Konzernen “mitgeschrieben” wurde. Diesbezüglich ist der CCC-Vortrag ” The Cloud Conspiracy 2008-2014 : how the EU was hypnotised that the NSA did not exist” unter https://media.ccc.de/v/31c3_-_6195_-_en_-_saal_g_-_201412272145_-_the_cloud_conspiracy_2008-2014_-_caspar_bowden#video&t=3661 höchst interessant.
Gruß
Roland
Hallo Roland,
Danke für Deine Feedback, ich hatte es nicht anders erwartet 😉
Wenn ich Deinen langen Kommentar lese, finde ich viele Rechtfertigungen. Ja der Matrix-Server “Synapse” ist als ein Homeserver für eine Anzahl Nutzer geeignet. Ja, einige der groben Datenschutzlücken sind abgestellt oder lassen wich umgehen. Aber die Tendenz bleibt: Es gibt den bequemen Identity-Server und der Nutzer wird beim Start eines Clients angehalten ihn einzutragen. Es gibt Tracking mit Opt-Out, warum?
Nicht jeder ist Willens und in der Lage zu Hause oder gar im Internet einen eigenen Matrix-Homeserver zu betreiben. Bei XMPP gibt es eine einfache Lösung: eine große Auswahl von professionellen Hosting-Anbietern. Bei Matrix bin ich auf einen der privaten Server-Betreiber angewiesen und muss den Account wechseln, wenn der Betreiber den Server wieder einstellt.
Zur Performance ein Zitat:
“The server matrix supports only one core in a multi-core processor. Matrix protocol is bloated and uses resources more than 10 times more than XMPP. Consumption is 10 times more than a rough count, some say consumption is 50 or even 100 times more if an attack occurs.”
Zitat von: https://mastodon.social/@xmpp/100889509419952247
Sehr schön. Vielen Dank euch beiden, damit haben wir ja viele Argumente zusammengetragen. 🙂
Ein paar Gedanken von meiner Seite:
1. Für Matrix spricht der (optional eintragbare!) Identity-Server: So kann man andere Nutzer leicht finden, wenn man den selbst betreibt. Das kann XMPP nicht. Allerdings gibt es auch bei XMPP das Konzept des “Shared Rosters”, mit dem man Kontakte innerhalb einer Organisation leicht finden kann.
2. Ich gebe zu, dass ich beim Betrieb eher an größere kirchliche Einheiten denke, die solche Technik verlässlich und rechtskonform betreiben können. Da spielt es schon eine Rolle, ob eine Serversoftware mit 10.000 Nutzern noch gut läuft.
3. Unter Aspekten einer “Green IT” und “digitaler Nachhaltigkeit” spielt informationstechnische Effizienz durchaus eine Rolle. Effiziente Software bedeutet nämlich nicht nur weniger belegte Hardwareressourcen, sondern auch weniger Energieumsatz.
4. Unter datenschutztechnischen Aspekten kann das socketbasierte “Fire and forget”-Messaging-System von XMPP (und auch Threema & Co.) durchaus ein Feature sein: Meine Daten werden dann nämlich nicht überallhin synchronisiert (und gespeichert). Sondern sie werden gelöscht, sobald sie übertragen sind (Prinzip der Datensparsamkeit). Unter diesem Aspekt wäre es wichtig, unter XMPP MAM (Message Archive Management, also das dauerhaft Speichern von Nachrichten) nur optional anzubieten. Umgekehrt wird Matrix (wo alles immer gespeichert wird) hier technisch wiederum anspruchsvoller, weil ich nur dann Kontrolle über meine Daten habe, wenn alles mit verlässlicher Ende-zu-Ende-Verschlüsselung unlesbar gemacht wird.
Ich warte gespannt auf Gegenargumente, die meinen den Wind aus den Segeln nehmen. 😉
Ich sehe in einen Diskussion pro/contra irgendetwas wenig Unterschiede zwischen “Argument” und “Rechtfertigung”, solange beides halbwegs fundiert belegt wird. Du kannst meinen Kommentar aber durchaus auch als “Rechtfertigung” bezeichnen, denn: Ich will freie, föderale Netze voranbringen (und keine schlechten, weil zentralisierten Alternativen wie Signal/Threema, die die eigentlichen Probleme nicht lösen). XMPP hat das trotz jahrelanger Alleinstellung in diesem Bereicht nicht geschafft – die Frage, warum das so ist, wird mir seitens der XMPP-Community nicht hinreichend selbstkritisch durchdacht.
Dann kam Matrix und bietet im Großen und Ganzen das, was XMPP technisch durchaus könnte, auch praktisch realisiert an, wird aber allseits eher negativ beurteilt, wobei die auf der Hand liegenden Vorteile größtenteils ignoriert werden.
Wie gesagt: Ein Großteil der User WILL über Mailadresse/Handynummer gefunden werden – und sei es nur, weil man den Umstand, dass es auch anders sein könnte, nicht (mehr) kennt. Das Konzept des Identity-Servers reagiert auf diesen Umstand und ist eine Übergangslösung für ebenfalls föderale Identity-Server.
Fakt ist aber, dass ich mitnichten gezwungen bin, dieses Konzept zu nutzen – und das ist doch bei genauer Betrachtung der Punkt, der zählt. Wer auf Datenschutz wert legt hat diesbezüglich durch Matrix/Riot keinerlei Nachteile, profitiert aber von den Vorteilen gegenüber XMPP und erst recht gegenüber Threema.
Es gibt eben kein “Tracking mit Opt-Out” (mehr), sondern, wie oben ebschrieben, Tracking mit *Opt-In*. Warum Entwickler Daten sammeln (auch das ehrwürdige Debian GNU/Linux fragt bspw. danach im Zuge einer “Package survey” im Installer), kann ganz pragmatische Ursachen haben. Wichtig bleibt, wie die Daten erhoben werden (und hier ist Piwik etwas anderes als Google Analytics) und ob ich dazu genötigt werde (auch hier sehe ich in einem Opt-In eine vertretbare Lösung).
Natürlich nicht. Deswegen gibt es matrix.org als prof. kostenlosen Referenz-Server und https://www.modular.im/ als erstes kommerzielles Angebot.
Was aber durchaus nur daran liegt, dass XMPP nunmal etliche Jahre länger “am Markt” ist. Die ständige Negativ-Stimmung, die gegenüber Matrix verbreitet wird, mit dem sich zu XMPP ja noch dazu bridgen lässt, hilft da nicht weiter. Matrix schließt XMPP mitnichten aus und wurde von Anfang an als “Protokolle verbindendes Protokoll” entworfen – auch das ignoriert Dein Artikel völlig.
Gleiches gilt doch aber auch für XMPP, wenn ich weder etwas zahlen noch einen eigenen Server betreiben will.
Das mag alles stimmen, hat aber bei einem breit gefächerten föderalen Netzwerk (was das Ziel sein sollte und durch Matrix nachweislich auch für Hobby-Admins niedrigschwelig ermöglicht wird) kaum Relevanz. Die erwähnten Vorteile des Matrix-Protokolls werden durch die einiseitige Betrachtung auf den “Ressourcenhunger” ignoriert und bleiben darüber hinaus ein rein administratives Problem: Die User interessiert es wohl kaum, wieviel Ressourcen ein Dienst frisst, solange dieser zuverlässig tut, was von ihm erwartet wird. Jedenfalls hat mir das Argument, dass “mein XMPP-Server ja so wenig Ressourcen verbraucht wenig”, absolut nichts gebracht, weil meine Familie über diesen nunmal (faktisch) nicht telefonieren kann und ständig Nachrichten verloren gingen, weswegen dann doch wieder propr. Services genutzt wurden. Oder anders: Du überzeugst niemandem mit FairTrade/Bio-Nahrung, wenn die guten Zutaten am Ende kein schmackhaftes Gericht ergeben (um die Grundbedürfnisse zu befriedigen, braucht FairTrad/Bio-Nahrung nicht unbedingt zu schmecken, *zufrieden* stimmt sie auf diese Weise aber am Ende die Mehrheit nicht).
Kurzum: Statt gegen Matrix zu argumentieren, sollten Synapse und Riot nicht nur kurz mal getestet, sondern aufgeschlossen produktiv genutzt werden, dann zeigen sich nämlich die massiven Vortile vor allem in Multi-OS-Umgebungen. Alles anderen (UI/Optik des Clients, Ressourcenhunger des Servers) werden aufgrund der erlebten Vorteile zu Nebensächlichkeiten. Aktuell scheint es mir so, dass Riot vielen XMPP-Usern schlicht “zu modern” anmutet (man ist halt die “Gajim-Tabellenkaluklationsoptik” gewöhnt und erwartet, dass freie, föderale Messenger nunmal so aussehen müssen).
Um auch mal eine Gegenposition einzunehmen und in meinen Augen *fundiertere* Gegenargumente gegen Matrix/Riot zu liefern:
Clientseitig stört mich sehr, dass Riot noch keine Multi-Accounts untersützt ( https://github.com/vector-im/riot-android/issues/120 ) und andere Matrix-Clients, die es können, dafür wiederum andere Features nicht mitbringen: https://matrix.org/docs/projects/clients-matrix
Aus Sicht eines Matrix-Admins stört mich extrem, dass es kein offizielles Support-Forum gibt. Ich will nicht in einem Chat Probleme schildern und dort auf Antworten warten müsen (auch das ist jedoch bei XMPP-Prosody genauso der Fall).
Danke Johannes auch für Deine Ergänzungen:
Ich finde den Ansatz, die User auf separate IDs hin zu “erziehen”, nach wie vor für zielführender. Was für Emailadressen selbstverständlich ist (es hätte ja auch jemand auf die Idee kommen können, Telefonnummern auf Emailadressen zu mappen, was glücklicherweise so nicht eintrat), sollte auch für Messenger der Fall sein. Dank des mit Emailadressen nicht verwechselbaren Matrix-ID-Formats ist es eigentlich kein Problem, bei entsprechenden Einführungen zu zeigen, wie man einen User per Matrix-ID hinzufügt (die man analog zu einer Emailadresse auch auf Visitenkarten oder in internen Adressverzeichnissen aufführen kann, ohne sie wie gesagt mit Emailadressen verwechseln zu können, was vielleicht auch ein Grund dafür ist, dass XMPP-Adressen sich auf Visitenkarten nicht durchgesetzt haben).
Gut, das ist dann ein anderer Denk-Ansatz. Auch hier könnte man jedoch überlegen, ob man die Kirchengemeinden (die man ja, wie bereits einmal auf der Mailingliste erwähnt, auch als föderales Netzwerk betrachten kann) zu kleinen IT-Rechenzentren erweitert, die dann durchaus zentral verwaltet werden können und so ein zentrales Rechenzentrum ersetzen. So hätte man einen föderalen Verbund (und damit nicht “alle Eier in einem Korb”), ohne kleine Gemeinden administrativ zu überlasten.
An dieser Stelle ärgert mich durchaus, dass ich den Stromverbrauch eines Cubietrucks nie vergleichend zum Verbrauch mit meinem akt. HP (ProLiant MicroServer Gen10) gemessen habe (ein 1-HDD-System wie ein Cubietruck ist jedoch bereits aus anderen Gründen für den produktiven Einsatz nicht vertretbar). Ein Server wie der besagte HP Gen10 taugt aber mit seinen 4 HDD-Slots durchaus für eine kleine Gemeinde, was den Schutz vor Datenverlust durch Hardwareschaden betrifft. Da meine Stromrechnung nicht signifikant gestiegen ist, behaupte ich mal, dass der Stromverbrauch durch Synapse im Rahmen geblieben ist (wobei ich Synapse ja auch schon auf dem Cubietruck am Laufen hatte, der nunmal nicht mehr als die ~5W aufnehmen konnte, die das Netzteil max. lieferte).
Unter diesem Aspekt wird allerdings auch nicht gegen Email als Kommunikationssystem argumentiert. Bei Email verliere ich ja auch die Möglichkeit, den Verbleib meiner Nachrichten zu kontrollieren, sobald ich an irgendeinen anderen Server im föderalen Mailserververbund schreibe.
Jedenfalls war diese Thematik ein großer Diskussionspunkt bei Matrix um Zuge der DSGVO-Einführung, auf die hin sich dann doch dazu entschieden wurde, einen “Lösche meinen Matrix-Account und alle jemals mit ihnen veröffentlichen Nachrichten”-Button anzubieten. Inwiefern das (wie bei Email) am Ende tatsächlich serverseitig umgesetzt wird, bezweifle ich.
Auch hier wäre ein pädagogischer Ansatz besser: Eine Nachricht, die ich nicht auch noch in 10 Jahren ruhigen Gewissens lesen könnte, sollte ich nicht in digitalen Systemen veröffentlichen.
Dann besteht aber wieder das Problem, dass die Nachrichtenverläufe im Multi-Device-Betrieb nicht unbedingt synchron sind – und das hat mich bei XMPP immer massiv gestört, weil ausgerechnet die Nachricht, die ich “jetzt gerade” am betreffenden Gerät brauchte, auf “dem anderen” war.
Gruß
Roland
Das möchte ich nur kurz korrigieren: Die datenschutzkonforme Nutzung von eMail ist nach meinem Kenntnisstand (ohne Gewähr, nichtjuristische Info!) derzeit nur möglich, wenn sichergestellt ist, dass alle beteiligten Kommunikationspartner den nötigen Datenschutzstandards entsprechen. Dieses Problem betrifft grundsätzlich alle dezentralen Netze und kann über drei Verfahren gelöst werden, wenn die dezentrale Funktionalität genutzt werden soll:
1. Blacklisting: Kommunikation über externe Stellen ist möglich bis ein Partner/Server ausgeschlossen wird, weil er nicht den Standards entspricht (Opt-Out).
2. Whitelisting: Kommunikation ist nur mit solchen externen Stellen möglich, die als vertrauenswürdige Partner/Server geprüft sind (Opt-In).
3. Ende-zu-Ende-Verschlüsselung bei sensiblen Daten: Es ist unkritisch, wenn Daten das eigene Netz verlassen, weil Unbefugte sie nicht einsehen können.
Der erste Fall entspricht mehr dem, was wir aus unserer Alltagswelt kennen. EU-Datenschutzverordnungen und Jurist_innen könnten vielleicht eher zum zweiten Fall tendieren. Der dritte Fall macht möglicherweise am wenigsten Probleme – solange die Verschlüsselung sicher ist. Ich würde eine Lösung mit Kombination der Fälle 1 und 3 bevorzugen.
Eine schöne Übersicht mit vielen Argumenten zu den unterschiedlichen Freien Messengern findet sich hier: https://www.freie-messenger.de/
Hihihi,
wird das hier jetzt die zweite Mailingliste für Luki-Admins 🙂
*Duck und wech*
Hallo Rainer,
Du bist immer so erfrischend 🙂
So eine lange Diskussion, obwohl die Meinungen so nah beieinander liegen.
Natürlich sind wir alle für freie, föderierende Messenger- und Chat-Lösungen.
Da gibt es Matrix und XMPP, leider beide nicht perfekt. Aber was ist schon perfekt? Die Feature der real existierenden kommerziellen und datenausspähenden Produkte ist deutlich kürzer. Wir diskutieren ja nur, ob der Matrixserver “Synapse” oder ein XMPP-Server wie “Ejabberd” und “Prosody” besser für einen produktiven Einsatz geeignet sind.
Gruß, Peter
Ich plane, den Thread hier zur besseren Übersichtlichkeit ins Wiki zu verschieben. Parallel wird Roland wohl eine Matrix mit verschiedenen Anforderungen für Messenger realisieren, sodass wir eine gute Übersicht haben.
Das Thema “fehlende Ende-zu-Ende-Verschlüsselung” bei föderierten Netzen betrifft natürlich zuerst auch die E-Mail und wird jüngst hier noch einmal problematisiert: https://www.heise.de/ix/heft/Mail-Ueberwachung-ohne-Ende-4196305.html
Hallo, in die Runde. Sehr interessante Diskussiona – vielen Dank. Roland Hummel – dein Blickwinkel entspricht meinem Ausgangspunkt. Dann kamen von verschiedener Seite Einwende, die mich ein wenig verunsicherten. Deshalb ist es interessant das alles hier noch mal so differenziert und abgewägt zu lesen. Ich finde Rolands Auflistung der 10 Punkte weiterhin sehr überzeugend.
Mich interessiert RIOT / Matrix auch deshalb weil ich auch denke, dass in Zukunft viele kleine Server Installationen entstehen werden, die sich die Last teilen. Auch hierzu hat sich 4∅4℃ITY in dem schon zitierten Thread geäußert:
https://bildung.social/@Nachbarschaft/100893157365764398
Roland, in wie weit sind die Äußerungen von “4∅4℃ITY” aus Deiner Sicht als relevant einzustufen?
_____
Ich habe auch Kontakt zu dem Admin von disroot.org ( übrigens ein sehr interessantes Portal). Dort hat man gerade entschieden RIOT /Matrix nach zwei Jahren Einsatz zurückzufahren um dafür xmpp mehr zu favorisieren.
Die Administration wäre die letzten zwei Jahre sehr aufwendig gewesen und eben auch die vielen Ressourcen die das System verschlinge, seien der Grund. Außerdem sei das System nicht wirklich offen für unabhängiger Entwickler, bzw. gibt es diese Entwicklerszene wie bei Xmpp nicht. Momentan sei Synapse und Riot nicht mit den offiziellen matrix Protokoll Spezifikationen kompatibel, was es noch mal schwerer mache eigene Server Software zu implementieren. Federführend ist ja auch wirklich eine Firma – verctor ltd – , die wohl schon länger angekündigt hat sich in eine gemeinnützige Stiftung zu wandeln, dies aber immer wieder nicht vollzieht. Aus diesem Grund hätte es auch schon eine Produktabspaltung/Fork (genannt „The Grid“) gegeben – das wäre kein gutes Zeichen.
Was ist von alle dem zu halten? Eure Meinung würde mich sehr interessieren.
Gruß
aus der Nachbarschaft
Hallo Nachbarschaft, vielen Dank für deinen Kommentar! Die Einschätzung, die du hier referierst entspricht soweit meinem Eindruck von der Matrix-Szene.
Der Gedanke einer “Lastverteilung” durch viele kleine Installationen ist an sich natürlich schlüssig. Ich denke auch hier aus der Sicht von Kirchengemeinden: Da muss ich feststellen, dass dafür vermutlich das Knowhow fehlt. So eine Installation in Übereinstimmung mit den Anforderungen an IT-Sicherheit und Datenschutz zu betreiben ist zudem beträchtlicher Aufwand. Das spricht dafür, die technische Infrastruktur auf einer übergeordneten Ebene mit eher “großen Installationen” zu bearbeiten.
Hi Johannes – also DU teilst die Einwende von „4∅4℃ITY“ nicht?
Hier noch nachträglich ein Link zu der offiziellen Erklärung auf disroot.org bezüglich RIOT /Matrix
https://disroot.org/en/blog/matrix-closure
Hi Nachbarschaft, ich habe keine der beiden Serversystem in dem Umfang wie geschildert betrieben. Aber das, was 404.city und disroot.org (Danke für den interessanten Link!) schildern, entspricht genau meinen Vorbehalten.
Diese Seite hier werde ich mit Informationen anreichern, ihr seid eingeladen, da gerne mitzutun: https://wiki.luki.org/doku.php?id=hosting:messenger_information (gleicher Zugang wie hier im Blog, Registrierung im Blog ist möglich).
Mein größtes Problem bei XMPP ist tatsächlich, dass ChatSecure als iOS-Client in meiner Wahrnehmung noch viel Liebe braucht, um an Conversations ranzukommen. Nur wenn die Clients auf beiden Plattformen stimmen, kann man Menschen davon gut überzeugen, denke ich. (Und das ist natürlich das große Plus von Matrix/Riot.)
Hallo Nachbarschaft,
entschuldige die späte Rückmeldung (@LUKi-Admins: Ich bekomme nach wie vor keine Mail-Benachrichtigung – geht es nur mir so?).
Zu Deiner Frage:
> https://bildung.social/@Nachbarschaft/100893157365764398
> Roland, in wie weit sind die Äußerungen von „4∅4℃ITY“ aus Deiner Sicht als relevant einzustufen?
Ich kommentiere mal die meinem Empfinden nach markantesten Aussagen:
> Matrix is experiencing problems at high loads
Ich habe nach über einem Jahr produktivem Betrieb keine derartigen Probleme feststellen können (und Server steht hinter einer schnöden Heim-DSL-Leitung). Ich kann problemlos dem Matrix-HQ mit seinen 10000+-Usern beitreten und dort mitchatten (wie auch den anderen offiziellen Support-Kanälen auf matrix.org mit den vielen Usern).
Selbst wenn Matrix im Vergleich zu XMPP extrem ineffizient arbeiten sollte, bekomme ich davon mit meinem kleinen Server nichts mit (16GB RAM insgesamt, 2GB für die Matrix-VM , da weitere VMs für andere Dienste parallel laufen und auch noch etwas “vom Kuchen” abbekommen müssen). Selbst wenn mir mein Monitoring “Lastspitzen” registriert, merke ich das nur, weil ich dann eine entsprechende Mail bekomme. Soetwas wie “Server-Schluckauf” während des Chattens/Telefonierens hatte ich nie.
> XMPP ready industrial standard. Matrix not ready for global use.
1. Wenn das so ist, warum entscheidet sich Frankreich, auf Basis von Matrix seinen offiziellen “Staats-Messenger” umzusetzen ( https://matrix.org/blog/2018/04/26/matrix-and-riot-confirmed-as-the-basis-for-frances-secure-instant-messenger-app/ )?
2. Dafür, dass Matrix “not ready for global use” ist, wird es meiner Ansicht nach ziemlich “global” eingesetzt, so zumindest entnehme ich das den oben genannten Serverlisten öffentlicher Matrix-Server.
> The more small servers, the greater the load.
Nungut, ich gebe mich gerne geschlagen, wenn ich irgendwann nicht mehr mit anderen Matrix-Usern kommunizieren kann. Bis dahin bleibt mit nichts anderes, als Matrix selbst in der aktuellen Implementierung mit Synapse ein “proof of concept” zu attestieren, weils nunmal im Gegensatz zu XMPP vollumfänglich sauber funktioniert. Dies zu behaupten nehme ich mir deswegen heraus, weil ich XMPP viele Monate getestet habe und XMPP in meinem Freundeskreis aus der Perspektive der “Alternativlosigkeit” (denn Matrix kannte ich zu diesem Zeitpunkt noch gar nicht) unter die Leute bringen wollte. Auf Matrix stief ich erst, als mir die iOS-User deutlich zu verstehen gegeben haben, dass sie “für sowas” nicht zu haben sind.
> Every small server on the network is a potential spammer or botnet member.
Wie auch bei Email – dafür gibt es Blacklisting. Ein “fire and forget”-System ist natürlich auch ein Matrix-Server nicht, was das Monitoring betrifft.
Weiter zu *Deinen* Aussagen:
> Außerdem sei das System nicht wirklich offen für unabhängiger Entwickler, bzw. gibt es diese Entwicklerszene wie bei Xmpp nicht.
Dagegen spricht in meinen Augen https://matrix.org/docs/projects/clients-matrix – 7 Clients, die neben Riot von der Community entwickelt werden.
Und wer ist denn “diese” XMPP-Szene? Prosody und ejabberd serverseitig, Conversations clientseitig? Alles andere an Clients kannst Du eigentlich vergessen, was moderne Anforderungen betrifft. Ist das jetzt die vielfältige XMPP-Szene?
Ich brauche ehrlich gesagt keine Vielfalt, solange ein bestimmtes freies System meine Anforderungen sehr gut erfüllt. Vielfalt ist gut und wichtig, aber wenn in der Vielfalt kein einziges System den Anfordungen gerecht wird, überzeugt man damit am Ende leider nicht.
> Momentan sei Synapse und Riot nicht mit den offiziellen matrix Protokoll Spezifikationen kompatibel, was es noch mal schwerer mache eigene Server Software zu implementieren.
> Federführend ist ja auch wirklich eine Firma – verctor ltd – , die wohl schon länger angekündigt hat sich in eine gemeinnützige Stiftung zu wandeln, dies aber immer wieder nicht vollzieht.
Beides interessante Infos. Gibts dazu konkrete Belege zum Nachlesen?
Aber: Selbst wenn das alles so sein sollte, würde ich trotzdem wieder Matrix wählen aus den dargestellten Gründen: Matrix setzt um, was aktuell XMPP nur (und viel zu lange schon) verspricht. Ich kann, und nur das zählt hier (leider) für mich, faktisch mit XMPP keine multi-OS-kompatible, freie, föderale Messenger-AV-Telefonie-Alternative zu WA anbieten. Und selbst wenn ChatSecure funktionieren würde, würde ich wieder zu Matrix greifen, weil ich bei Riot alle Plattformen unterstützen kann, was den First-Level-Support betrifft (wer einen anderen Matrix-Client will, darf sich entsprechend selbst helfen – aber wenn ich den Leuten schon etwas “andrehe”, muss ich sie auch supporten und da will ich mir das Leben so leicht wie möglich machen).
Solange Matrix freie Software bleibt, ist es mir ehrlich gesagt auch egal, wenn sich die Matrix-Devs mit ihrer Entwicklung irgendwie “eigenwillig” verhalten (das stört uns bei Linux Torvalds auch nicht – solange er seine Sache gut macht und die Community dank freier Software jederzeit die Möglichkeit behält, andere Wege zu gehen).
> Was ist von alle dem zu halten?
Mein abschließender Rat an Dich: Vertraue weder mir noch anderen, sondern setz einen eigenen Matrix-Server auf, benutz ihn ein, zwei Monate mit einem Kreis auserwählter Tester*innen intensiv als Standard-Messenger im Alltag (aber achte darauf, dass alle gängigen Plattformen vertreten sind, also: Win/Mac/Linux/iOS/AndroidMitGApps/AndroidOhneGappsMitF-Droid – darunter sollte möglichst wenigstens eine Person sein, die auf einem OS unterwegs ist, das Du *nicht* benutzt und von all dem wenig Ahnung hat, sodass Du in die Rolle gezwungen wirst, Support auf einem *fremden* OS leisten zu müssen, denn hier wird es im Alltag zeitaufwendig und kritisch).
Wenn Du danach immernoch Bedarf hast, XMPP zu testen, wiederhole den Test mit XMPP.
Diese Reihefolge lege ich Dir deswegen nah, weil ich den Stress, den ich hatte, niemandem antun möchte – ich will aber genauso wenig ausschließen, dass anderen “Hobby-Admins” gelingt, was mir (leider) nicht gelang. Am Ende zählen nur Deine persönlichen Erfahrungen, denn Du musst das möglichst 24/7 am laufen halten. Falls Du Hilfe brauchst, melde dich gerne.
Gruß
Roland
Hallo Roland,
die XMPP Community ist das,was ich mir unter “Federation” vorstelle. Wie bei E-Mail mit SMTP kommunizeren viele Server mit unterschiedlicher Software von unterschiedlichen Entwicklern miteinander. Da ist Matrix mit einer einzigen funktionierenden Server-Software noch Jahre von entfernt. Auch wenn es sieben Projekte gibt, die Clients in der Entwicklung haben.
Du nennst in Deinem letzten Kommentar EJabberd und Prosody. Ohne groß nachzusehen fallen mir einige weitere Server mit FOSS-Lizenzen ein: Jabberd2, Tigase, Openfire, Apache Vysper.
Mein FDroid auf Android listet mit ungefähr ein halbes Dutzend XMPP-Chat-Clients auf. Unter https://omemo.top finde ich acht Clients, die OMEMO komplett beherrschen. Einige mehr haben OMEMO in Arbeit.
Ich würde mich freuen, wenn das Matrix Protokoll in ein paar Jahren auch soweit ist.
Viele Grüße, Peter
Hallo in die Runde,
Die Quellen zu dem was der admin von disroot.org mir schrieb werden wohl in dem Entwicklerforen von Matrix und Riot zu finden sein. Disroot ist ein großes Projekt was ich sehr ernst nehme. Ich glaube nicht dass dort Entscheidungen leichtfertig fällt werden.
Aber Roland, deine Argumente finde ich immer noch sehr überzeugend und sprechen mich sehr an.
Als hobby admin möchte ich in die Position kommen anderen Gruppen Empfehlungen zu geben. Das wird nur über das selber ausprobieren gehen. Alles was DU gemacht hast steht mir also noch bevor, und ich nehme gerne Dein Hilfsangebot an. Wie kann ich Dich kontaktieren? Vielleicht auch mal per Telefonieren?
bis bald
und Grüße aus der Nachbarschaft
Hallo Nachbarschaft,
> Wie kann ich Dich kontaktieren? Vielleicht auch mal per Telefonieren?
klick auf meinen Namen -> “Kontakt” -> “Jahr 1 nach Snowden”.
Gruß
Roland
habt ihr eigentlich dieses Schriben von der EKD mitbekommen:
https://datenschutz.ekd.de/wp-content/uploads/2018/10/Erg%C3%A4nzende-Stellungnahm-Messgr-Dienste.pdf
was wird jetzt wohl passieren?
Hallo Nachbarschaft,
ja, über diesen Link bei katholisch.de sind wir darauf aufmerksam geworden:
https://www.katholisch.de/aktuelles/aktuelle-artikel/ekd-datenschutzer-verbietet-whatsapp-und-telegram
Die Stellungnahme zielt genau in die richtige Richtung. Besonders der Satz “Die Entwicklung sowie der Einsatz und Betrieb eines eigenen Messenger-Dienstes in Kirche und Diakonie auf Basis von etablierten und frei zugänglichen Protokollen auf föderalen Servern wäre aus Sicht des Beauftragten für den Datenschutz der EKD die beste Lösung und wird daher empfohlen.” ist Wasser auf unsere Mühlen.
Wenn sich etwas bewegt, dann nur langsam. Wir müssen bei den Menschen noch sehr viel Überzeugungsarbeit leisten.
Gut differenziert ich auch diesen Beitrag von Benjamin Wockenfuß:
https://www.benjamin-wockenfuss.de/2018/07/19/der-un-sinn-mit-whatsapp/
Er rät dazu eine Messenger-Gruppe zum Beispiel für Kindergarteneltern explizit nicht bei WhatsApps einrichten, um zu zeigen dass es mehr als einen Messenger gibt.
Wir bei LUKi wollen zeigen, dass es Alternativen gibt. Dazu suchen wir Leute, die und finanziell und tatkräftig unterstützen. Ein Referenzprojekt soll zeigen, dass Alternativen praxistauglich sind.
Viele Grüße,
Peter
wenn ich mir überlege wie viel Gemeinden es in Deutschland gibt – also wie viel Bedarf – dann sollte es doch für das finazielle Lösungen geben. Bei der Tatkraft sind nun die gefordert die sich auskennen – luki e.V. ? Warum stellt die EKD nicht Mittel dafür bereit dass es vorran geht?