Hallo zusammen,
ich habe noch eine Frage und wäre auch hier für einen Tipp dankbar: Welche freien Alternativen zu Whatsapp/Threema-Gruppen [0], die auch für Laien verwendbar sind, gibt es?
Für die Kommunikation mit einer einzelnen Person habe ich bisher sehr gute Erfahrungen mit XMPP gemacht: Conversations [1] als Client unter LineageOS / Android und Prosody [2] (mit ein paar Erweiterungen [3]) als Server unter Debian.
Viele Grüße
Stefan
[0] Gruppenchat auf mobilen Geräten, die keine ständige Verbindung zum Server haben [1] https://conversations.im/ [2] https://prosody.im/ [3] https://modules.prosody.im/
Hi Stefan,
dieser Frage sind eine Gruppe unverbesserlicher WA-Verweigerer und ich einige Monate nachgegangen und am Ende beim Matrix-Protokoll (Client: Riot.im) gelandet.
Vorher hatten wir XMPP (Prosody) lange im Test, die Client-Lage unter iOS war aber mehr als dürfitg (nicht in Bezug darauf, dass es für iOS keine XMPP-Clients gibt, sondern, dass diese spätestens in MUCs große Probleme gemacht haben, entweder weil der OMEMO-Schlüsselaustausch nicht funktionierte oder weil Nachrichten nicht durchkamen). Auch unabhängig von der iOS-Problematik kamen bei XMPP immer mal wieder nicht reproduzierbar Nachrichten nicht an und die Fehlermeldungen waren nicht eindeutig (also: Fehlermeldung, dass eine Nachricht nicht übermittelt wurde, sie kam aber an - keine Fehlermeldung, wenn eine Nachricht angeblich übermittelt wurde, die aber nie ankam). Zusätzlich fand ich (als "Feierabend-Admin") die Server-Administration von Prosody im Vergleich zu Matrix (Synapse) extrem aufwendig (Synapse war an einem Nachmittag aufgesetzt und lief out of the box, bei Prosody muss man ja schon eine ganze Reihe mehr oder weniger gut dokumentierter XEP-Erweiterungen installieren, um eine gewohnte Messenger-Basis-Funktionalität zu haben - das laste ich nicht dem XMPP-Protokoll an, wohl aber der teilweise dürftigen Prosody-Dokumentation - aber vielleicht war ich auch einfach nur zu unfähig für Prosody ;) ).
Kurzum: Das einzige, was an föderalen Protokollen plattformübergreifend (inkl. F-Droid) und mit dem Anspruch an föderale Netze out of the box funktionierte war Matrix mit Riot.im.
Mein "Wasserstand" zur "Messenger-Frage" ist daher dieser:
Warum Matrix und nicht...
...Briar? -> frei, dezentral (peer-to-peer), nur Textnachrichten (keine Bilder), nur Android ...Delta Chat? -> frei, dezentral, funktional limitiert (nutzt E-Mail), nur Android ...Telegram? -> serverseitig proprietär, zentralisiert ...Threema? -> client- und serverseitig proprietär, zentralisiert ...KakaoTalk? -> client- und serverseitig proprietär, zentralisiert ...Ring? -> frei, dezentralität (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 ...XMPP? -> lange Favorit, frei, dezentral, leider große Probleme unter iOS/Apple
Alle "Bewertungen" beziehen sich auf einen Testzeitaum von Okt. 2016 bis Nov. 2017. Korrigiert mich gerne, aber nichts davon ist irgendwie abgeschrieben, sondern basiert auf eigenen Tests. Ergänzungen willkommen.
Die Bewertungskategorien waren demnach:
- Freie Software für Clients und Server - dezentraler/föderaler Betrieb möglich - Clients für Windows/GNU-Linux/Mac/Android/iOS - keine Bindung an Telefonnummer - absolut verlässlicher Nachrichtentransfer - e2e-Verschlüsselung in Einzel- und Gruppenchats möglich
Gruß Roland
On 01/21/2018 09:56 AM, Stefan wrote:
Hallo zusammen,
ich habe noch eine Frage und wäre auch hier für einen Tipp dankbar: Welche freien Alternativen zu Whatsapp/Threema-Gruppen [0], die auch für Laien verwendbar sind, gibt es?
Für die Kommunikation mit einer einzelnen Person habe ich bisher sehr gute Erfahrungen mit XMPP gemacht: Conversations [1] als Client unter LineageOS / Android und Prosody [2] (mit ein paar Erweiterungen [3]) als Server unter Debian.
Viele Grüße
Stefan
[0] Gruppenchat auf mobilen Geräten, die keine ständige Verbindung zum Server haben [1] https://conversations.im/ [2] https://prosody.im/ [3] https://modules.prosody.im/ _______________________________________________ FSFE-de mailing list FSFE-de@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/fsfe-de
Hallo Roland,
vielen Dank für Deine E-Mail!
On 21.01.2018 11:15, Roland Hummel wrote:
Kurzum: Das einzige, was an föderalen Protokollen plattformübergreifend (inkl. F-Droid) und mit dem Anspruch an föderale Netze out of the box funktionierte war Matrix mit Riot.im.
Ich habe riot.im gerade einmal ausprobiert. Gefällt mir gut.
(Hinweis für andere Leser: Das Registrieren neuer Accounts mit dem Standard-Server matrix.org funktioniert im Android-Client leider nicht. Eine Registrierung über https://riot.im/app ist aber möglich.)
Hast Du auch Erfahrungen, wie gut das Telefonieren mittels Riot.im funktioniert?
Viele Grüße
Stefan
Hallo Stefan,
On 01/21/2018 02:37 PM, Stefan wrote:
(Hinweis für andere Leser: Das Registrieren neuer Accounts mit dem Standard-Server matrix.org funktioniert im Android-Client leider nicht. Eine Registrierung über https://riot.im/app ist aber möglich.)
Achso? Mir wurden die letzten Tage eigentlich keine Probleme gemeldet (und das von vielen, die sofort streiken würden, wenn sie sich erst über eine Webseite einen Account anlegen müssten).
Vielleicht wichtig in diesem Zusammenhang: der Identitätsserver (den man bei der Anmeldung in Riot über die Option "Custom server" einstellen kann) stellt eine auch für die Matrix-Entwickler unschöne Kompromisslösung dar, damit sich User mit einem mittlerweile leider vorausgesetzten Komfort auch ohne Weitergabe der sog. Matrix-ID (@user:matrix-server.tld) gegenseitig adden können (also bspw. über Telefonnummer oder Email-Adresse). Leider sind die Identitätsserver aktuell zentralisiert und speichern alles an Adressdaten, was man ggf. in seinem Profil angegeben hat (Email bspw. für die Passwort-Reset-Funktion), um auch darüber im Matrix-Netzwerk gefunden werden zu können.
Wichtig: für die allg. Nutzung von Matrix ist die Angabe eines Identity-Server aber in keinem Fall nötig und wenn man sich daran gewöhnt hat, eine Messenger-Adresse genauso im Telefonbuch abzuspeichern wie Telefonnummer und Email, auch kein wirklich Komfortverlust.
Hast Du auch Erfahrungen, wie gut das Telefonieren mittels Riot.im funktioniert?
Keine, die ich als repräsentativ darstellen würde. Ich habe es bisher nur über meinen eigenen Matrix-Server ausprobiert und da funktionierte es "solala" (manchmal perfekt auch mit Video trotz Heim-DSL-Leitung, manchmal überhaupt nicht). Ich habe aber gestern erst festgestellt, dass mir ein Fehler in der Port-Konfiguration des nötigen TURN-Servers unterlaufen ist, wodurch die Probleme eventuell behoben wurden. Ich vermute mal, dass es über den Server der Entwickler problemlos funktionieren wird.
Gruß Roland
Hallo Roland,
On 21.01.2018 18:27, Roland Hummel wrote:
Hallo Stefan,
On 01/21/2018 02:37 PM, Stefan wrote:
(Hinweis für andere Leser: Das Registrieren neuer Accounts mit dem Standard-Server matrix.org funktioniert im Android-Client leider nicht. Eine Registrierung über https://riot.im/app ist aber möglich.)
Achso? Mir wurden die letzten Tage eigentlich keine Probleme gemeldet (und das von vielen, die sofort streiken würden, wenn sie sich erst über eine Webseite einen Account anlegen müssten).
Bei der Desktop-Version (installiert unter Arch Linux) von Riot.im stand bei mir, dass eine Registrierung bei matrix.org über den Client nicht möglich ist, weil ein CAPTCHA verlangt wird. Unter Android kam einfach eine nichtssagende Fehlermeldung (ich habe Roit.im über F-Droid installiert).
Noch eine allgemeine Frage: Kann man irgendwie einschätzen, welche Server seriös sind?
Viele Grüße
Stefan
On 01/21/2018 08:02 PM, Stefan wrote:
Bei der Desktop-Version (installiert unter Arch Linux) von Riot.im stand bei mir, dass eine Registrierung bei matrix.org über den Client nicht möglich ist, weil ein CAPTCHA verlangt wird. Unter Android kam einfach eine nichtssagende Fehlermeldung (ich habe Roit.im über F-Droid installiert).
Ah, dann ist klar, ich dachte Du hattest Riot erstmal "standardmäßig" über den PlayStore installiert (hier wurden mir nie Probleme gemeldet von Usern, die es darüber installiert hatten). Probleme unter unseren "Abweichler*innen-Systemen/Plattformen" sind für mich mittlerweile Standard, daher aber auch keine Probleme mehr, sondern akzeptierte (und dennoch glückliche) Lebenswirklichkeit.
Vielleicht in diesem Zusammnhang auch noch wichtig: die F-Droid-Version von Riot hat eine Autostart-Option. Die sollte auch aktiviert werden, weil die F-Droid-Version sonst nach einem Handyneustart keine Nachrichten gepusht bekommt (da ja ohne GAPPS auch GCM fehlt, worüber normalerweise gepusht wird).
Noch eine allgemeine Frage: Kann man irgendwie einschätzen, welche Server seriös sind?
Nein, aber https://www.hello-matrix.net/public_servers.php kann man analog zu einer XMPP-Serverliste auch schwer auf Seriosität prüfen. Dafür gibt es ja dann im Zweifel die E2E-Verschlüsselung.
Gruß Roland
Hallo Roland,
vielen Dank für Deine E-Mail.
On 21.01.2018 18:27, Roland Hummel wrote:
Hallo Stefan,
On 01/21/2018 02:37 PM, Stefan wrote:
(Hinweis für andere Leser: Das Registrieren neuer Accounts mit dem Standard-Server matrix.org funktioniert im Android-Client leider nicht. Eine Registrierung über https://riot.im/app ist aber möglich.)
Achso? Mir wurden die letzten Tage eigentlich keine Probleme gemeldet (und das von vielen, die sofort streiken würden, wenn sie sich erst über eine Webseite einen Account anlegen müssten).
Auf einem Telefon gab es gestern auch bei der Installation über Google Play Probleme. Es erschien die Meldung "Dieser Home-Server möchte sicherstellen, dass du kein Roboter bist". Ansonsten wurde einfach nichts angezeigt. Nach einer Neuinstallation war das Problem aber behoben.
Vielleicht wichtig in diesem Zusammenhang: der Identitätsserver (den man bei der Anmeldung in Riot über die Option "Custom server" einstellen kann) stellt eine auch für die Matrix-Entwickler unschöne Kompromisslösung dar, damit sich User mit einem mittlerweile leider vorausgesetzten Komfort auch ohne Weitergabe der sog. Matrix-ID (@user:matrix-server.tld) gegenseitig adden können (also bspw. über Telefonnummer oder Email-Adresse). Leider sind die Identitätsserver aktuell zentralisiert und speichern alles an Adressdaten, was man ggf. in seinem Profil angegeben hat (Email bspw. für die Passwort-Reset-Funktion), um auch darüber im Matrix-Netzwerk gefunden werden zu können.
Wichtig: für die allg. Nutzung von Matrix ist die Angabe eines Identity-Server aber in keinem Fall nötig und wenn man sich daran gewöhnt hat, eine Messenger-Adresse genauso im Telefonbuch abzuspeichern wie Telefonnummer und Email, auch kein wirklich Komfortverlust.
Wenn man eine Standardinstallation durchführt, ist der Identitätsserver vector.im voreinstellt. Ist die Verwendung des Identitätsservers aus Datenschutzsicht unkritisch, wenn man keine Telefonnummer oder E-Mail-Adresse eingibt und den Telefonbuchzugriff sperrt?
Gibt es eine Beschreibung, was bei einem Telefonbuchabgleich über den Identitätsserver mit den hochgeladenen Daten passiert?
Die Privacy Policy [1] von Riot gibt darüber leider keine Auskunft. Allerdings finden ich u.a. folgenden Absatz unter der Überschrift "What kinds of information do we collect?" etwas störend:
"the communication content that you send and receive while using our Service. This may include message content and timing information, including text, photo, video and other media files in the context of the communication history of a room. This content may be encrypted by your client;"
Habt Ihr untersucht, was die Riot-App im Detail macht? Verbindet sich diese direkt mit dem Matrix-Server, den man angegeben hat oder werden die Daten über einen Dienst von Riot geleitet, der als Proxy fungiert? Werden ansonsten Daten von der App erfasst und an die Hersteller von Riot übermittelt? In F-Droid wird folgendes Anti-Feature genannt: "Includes opt-out Piwik analytics.". Eine Möglichkeit zur Deaktivierung von Piwik habe ich in der App bisher nicht gefunden.
Viele Grüße
Stefan
Roland Hummel wrote:
...Delta Chat? -> frei, dezentral, funktional limitiert (nutzt E-Mail), nur Android
Moin Roland,
da ich Delta tatsächlich für den hier angesprochenen Einsatzzweck viel & gerne verwende - was meinst Du mit funktional limitiert?
Bzgl. iOS: https://github.com/deltachat/deltachat-ios (ok, noch nicht fertig, aber hey). :)
Liebe Grüße,
-- Thorsten
Hallo Thorsten,
On Sun, 21 Jan 2018 22:07:49 +0100 Thorsten Behrens wrote:
Roland Hummel wrote:
...Delta Chat? -> frei, dezentral, funktional limitiert (nutzt E-Mail), nur Android
Moin Roland,
da ich Delta tatsächlich für den hier angesprochenen Einsatzzweck viel & gerne verwende - was meinst Du mit funktional limitiert?
ich habe DeltaChat auch eine Zeit lang ausprobiert, vor allem für Kontakte von denen ich zwar eine E-Mail Adresse hatte die aber ansonsten nur WhatsApp & Co. verwenden.
Weswegen ich es mittlerweile aber nur noch sehr selten verwende hat mehrere Gründe:
- Ende-zu-Ende Verschlüsselung ist für mich heutzutage ein muss. Wenn ich DeltaChat nehme um Leuten Nachrichten zu schreiben die selber kein DeltaChat verwenden ist alles unverschlüsselt. Irgendwie habe ich das Gefühl, das man sich einen Bärendienst erweist wenn man E-Mail als alternative zu WhatsApp & Co empfiehlt.
- Nachrichten zwischen DelatChat Benutzern (wobei ich das nie hatte) sind GnuPG verschlüsselt. Um aber den gleichen Schlüssel wie für meine anderen Mails zu verwenden müsste ich das Passwort entfernen -> keine Option. Aber wenn die Nachrichten in meiner Mailbox landen, dann will ich sie auch ohne DeltaChat öffnen können.
- Da DeltaChat für jedes Bild und jeden Einzeiler eine neue E-Mail verschickt hatte ich mit der Zeit ein schlechtes Gewissen Leute mit vielen kurzen Mails zu belästigen. Meiner Meinung nach müsste es hier eine sinnvolle Gruppierung geben. Was aber zugegeben schwer umzusetzen ist.
Das sind meine Gründe weswegen für mich DeltaChat am Ende ein super spannender Ansatz ist, aber eben doch keine wirkliche Alternative war.
Für mich persönlich ist momentan Signal der kleinsten gemeinsame Nenner, wo man es gerade noch schaffen kann andere Leute davon zu überzeugen. Selbst das ist schon schwer genug. Ansonsten verwende ich auch regelmäßig XMPP, aber eben nur mit einem ganz bestimmten Kreis von Leuten. XMPP dem Otto-Normalanwender näher zu bringen halte ich aus meinen persönlichen Erfahrungen heraus für aussichtslos.
Viele Grüße, Björn
Entschuldigt die späte Antwort, ich bearbeite alle 3 Anfragen an mich hier zusammen:
On 01/24/2018 10:14 PM, Bjoern Schiessle wrote:
da ich Delta tatsächlich für den hier angesprochenen Einsatzzweck viel & gerne verwende - was meinst Du mit funktional limitiert?
Ich finde den DeltaChat-Ansatz genial, glaube aber nicht, dass AV-Chats damit jemals möglich sein werden, weil das Email-Protokoll nunmal nicht dafür entwickelt wurde. Und obwohl der Anspruch, mit einem Messenger telefonieren zu können, bei genauer Betrachtung eigentlich wahnsinnig überzogen ist, werde ich hier die Diskussionen mit der WA-Fraktion unmöglich gewinnen, weil die dann sagen: "Ja, alles toll, ich will aber nunmal auch telefonieren können, wenn ich im Ausland bin". So eine Diskussion werde ich nicht damit gewinnen, zu sagen, dass ich mit meinem Notebook auch gerne Spiegeleier braten können würde.
Unterm Strich war Matrix halt das, was wir uns von XMPP erhofft hatten, sich aber auch ohne zwanzigjährige Administrationserfahrung betreiben ließ.
Randbemerkung: mein Test von Delta-Chat scheiterte schon damit, dass meine Uni-Adresse andere Ports nutzt (993 für den Posteingangsserver) und Delta-Chat damit eventuell nicht klar kommt: ein Nachrichtenaustausch war schlicht nicht möglich, alle Nachrichten landeten immer nur in meinem Postfach. Und wenn es schon mit einem Provider nicht out of the box funktioniert, der für gut 40000 User Emailadresse bereitstellt, will ich nicht wissen, was mich da langfristig erwartet hätte ("ihr braucht einfach nur eure Emailadresse, nichts weiter - außer ihr seid bei Provider X, Y und Z, dann bitte einen anderen nutzen). Ich hatte das Problem auch den Entwicklern gemeldet, schien unbekannt zu sein.
On 01/24/2018 10:14 PM, Bjoern Schiessle wrote:
Für mich persönlich ist momentan Signal der kleinsten gemeinsame Nenner, wo man es gerade noch schaffen kann andere Leute davon zu überzeugen. Selbst das ist schon schwer genug. Ansonsten verwende ich auch regelmäßig XMPP, aber eben nur mit einem ganz bestimmten Kreis von Leuten. XMPP dem Otto-Normalanwender näher zu bringen halte ich aus meinen persönlichen Erfahrungen heraus für aussichtslos.
Wie gesagt: publiccode.eu will doch im Kern darauf hinaus, zivilgesellschaftlich kontrollierbare IT-Infrastrukturen zum Standard zu erheben (zumindest ist das meine Interpretation dessen, was da eigentlich gefordert wird). Solange Signal keine föderales Protokoll ist, ist dieser Anspruch nicht gegeben und damit in meinen Augen auch ungünstig investierte Überzeugungsarbeit.
On 01/24/2018 08:48 AM, Bernhard Reiter wrote:
Hallo Roland,
vielen Dank fürs Aufschreiben Deiner Erfahrungen, das bringt uns alle
weiter.
Gerne, freut mich, dass die Liste hilft.
a) Kannst Du das näher erklären? Es scheint ja welche zu geben, die in
Deinem
Test durchgefallen sind.
https://xmpp.org/software/clients.html listet vier iOS Klienten, davon erscheinen mindestens die folgenden eine Erstprüfung auf Freie
Software zu
bestehen:
https://github.com/ChatSecure/ChatSecure-iOS oder eine Variante https://github.com/zom/Zom-iOS https://tigase.tech/projects/tigase-ios-messenger/repository
Wir hatten ChatSecure genommen, Tigase und Zom waren mir zugegebenermaßen zum damaligen Zeitpunkt nicht bekannt, was auch daran liegt, dass ich selbst keine Apple-Hardware besitze und für Tests immer nur mal kurz ein Leihgerät nutzen konnte.
Jedenfalls war ChatSecure nicht zu gebrauchen, da man hier nicht selbständig wie bei Conversations den Verschlüsselungsmodus einstellen kann, sondern der Client dies automatisch macht je nachdem, was die "Gegenstelle" benutzt. Das sah dann in der Praxis so aus, dass Conversations mit OMEMO eine Nachricht schrieb und dann ein wahres "Funkfeuer" an OTR-Handshake-Anfragen losging. In MUCs ging meist überhaupt nichts, schon das Beitreten war eine Katastrophe (MUC war aus sich des iOS-Clients leer, keine Userliste etc, Nachrichten kamen nicht durch).
Was damals gut funktionierte war "AstraChat", aber das ist 1. proprietär, kann 2. kein OMEMO (soweit ich mich erinnere konnte es überhaupt nicht verschlüsseln) und speicherte 3. alle Mediendateien auf den Servern des Herstellers - also eine Katastrophe. Zumindest funktionierte hier aber MUCs problemlos und der Nachrichtenaustausch generell.
dass diese spätestens in MUCs große Probleme gemacht haben, entweder weil der OMEMO-Schlüsselaustausch nicht funktionierte oder weil Nachrichten nicht durchkamen).
Das scheinen dann Implementierungsprobleme der XMPP Klienten auf iOS
zu sein,
richtig? Da XMPP sonst interessant erscheint (weil standardisierte Protokollvarianten), würden sich vielleicht Problemberichte lohnen.
Wie gesagt: ich hatte dann aus Frust bezüglich der Server- und iOS-Probleme mal Matrix (Synapse) auf meinem Testserver installiert, war überrascht, wie relativ einfach das ging, alles out of the box klappte und man auch mit Matrix ein offenes Protokoll hat. Aufgrund der Tatsache, mit Riot.im einen plattformübergreifenden (!) Referenz-Client zu haben, der ja auch auf jeder Plattform gleich aussieht, war dann relativ schnell klar, zu Matrix zu wechseln, schon allein deswegen, weil wir hier aufgrund der gleichen Optik auf allen Systemen nur eine Anleitung schreiben mussten, die für jedes "Ökosystem" gültig war. Abschließend gibt man ja die Verbindung zum XMPP-Netzwerk ja durch Matrix auch nicht endgültig auf, da das Matrix-Protokoll von Anfang an darauf ausgelegt wurde, in jedes andere Netzwerk "bridgen" zu können, das dies irgendwie zulässt. Ich bin allerdings noch nicht dazu gekommen, so eine Bridge mal zu testen.
Das wäre dann allgemeine XMPP Probleme mit den Protokollvarianten oder
denkst
Du das es dabei auch um die Server-Implementation geht?
Die Ursachen könnten viele sein, bis zu dem Verdacht, dass der Flash-Speicher meines ARM-Systems, das ich als Testserver genutzt habe, Fehler hat. Da Matrix aber auch auf dem ARM-System keine Probleme machte, denke ich nicht, dass meine Hardware das Problem war.
Ich sehe ein, dass die Flexibilität von XMPP auch ein Vorteil ist: standardmäßig kann bspw. Prosody in der Version, die ich damals getestet hatte, nur Einzelchats (wer nicht mehr benötigt, hat damit ein schlankes System). Schon für MUCs musste man eine Erweiterung aktivieren, dann für Message Archive Management, usw usw. Dieser Ansatz führt allerdings dazu, dass man eben nicht mehr davon ausgehen kann, eine gewisse Basis-Funktionalität bei einem XMPP-Provider vorzufinden. Beispiel: wenn ich riseup.net nutze (und das ist ja nun nicht "irgendein" Provider) kann ich in MUCs keine Bilder verschicken, in Einzelchats aber schon. Erklär das mal einem "Normalnutzer", dem Du einen riseup-Account geschenkt hast - so macht Überzeugungsarbeit keinen Spaß. Hier kann Matrix (aber natürlich nur, weil es eine so junge Entwicklung ist) von Anfang an eine Basisfunktionalität garantieren und ich (zumindest bis jetzt) entspannt auf https://www.hello-matrix.net/public_servers.php verweisen, weil ich davon ausgehen kann, dass die gewohnten Funktionalitäten (Gruppenchats mit Medien-Uploads-Möglichkeit) überall funktionieren.
Gruß Roland
Moin Björn, *,
Bjoern Schiessle wrote:
- Ende-zu-Ende Verschlüsselung ist für mich heutzutage ein muss. Wenn ich DeltaChat nehme um Leuten Nachrichten zu schreiben die selber kein DeltaChat verwenden ist alles unverschlüsselt. Irgendwie habe ich das Gefühl, das man sich einen Bärendienst erweist wenn man E-Mail als alternative zu WhatsApp & Co empfiehlt.
Yeps, das ist so. Allerdings ist da grade viel in Bewegung gekommen, mit dem autocrypt-Standard. K-9 und Enigmail sollten das IIRC in der jeweils nächsten Version unterstützen.
Aber Du hast natürlich Recht, dass das für unbedarfte Standardnutzer schlecht kontrollierbar ist...
Viele Grüße,
-- Thorsten
On Thu, 25 Jan 2018 22:24, thb@documentfoundation.org said:
mit dem autocrypt-Standard. K-9 und Enigmail sollten das IIRC in der
Das Schöne an Standards ist es, daß es so viele davon gibt.
Wenn ein Programmierer zu faul ist, einen MIME Parser zu benutzen, dann werden Daten einfach in den RFC-822 Header geworfen und das als Standard bezeichnet. Der Standard um OpenPGP Keys zu versenden ist allerdings seit 22 Jahren RFC-3156 (vormals RFC-2015). Wer darüberhinaus weitere Metadaten transportieren will, kann dies immer noch in MIME Headern des application/pgp-keys Parts machen.
SCNR,
Werner
Am Donnerstag 25 Januar 2018 22:24:39 schrieb Thorsten Behrens:
Irgendwie habe ich das Gefühl, das man sich einen Bärendienst erweist wenn man E-Mail als alternative zu WhatsApp & Co empfiehlt.
Yeps, das ist so. Allerdings ist da grade viel in Bewegung gekommen, mit dem autocrypt-Standard.
Aus meiner Sicht ist https://wiki.gnupg.org/WKD der bessere Ansatz. (Das liegt wohl auch daran, dass ich ihn mit entwickelt habe. :) Was ich schade finde, ist dass die autocrypt Leute unseren früher veröffentlichen Ansatz kannten und sich nicht die Mühe gemacht haben uns Rückmeldung dazu zu geben, wo sie unsere Argumentation nicht teilen.)
Es liegt jetzt daran, wieviele Email-Provider und Email-Klienten die weitergehenden Möglichkeiten implementieren. Posteo ist schon recht weit. Mailbox.org bietet die Abfrage ab Q2 2018 an.
Die aktuelle GnuPG-Version 2.2 kann die Abfrage bereits (*), Email-Klienten können zu meiner Email-Addresse bernhard@intevation.de direkt einen öffentlichen Schlüssel mit Basisvertrauen bekommen und dann automatisch verschlüsseln.
Die Verteilung der öffentlichen Schlüssel rein per Email hat den Nachteil, dass Basisvertrauen nur durch zeitliche verlaufende Infos entstehen kann und die Regel dafür sind für Nutzer deutlich komplizierter zu verstehen. (Und mehr Platz verbraucht es auch und ich meine dabei sogar Probleme mit den MIME-Standards gesehen zu haben.)
Gruß, Bernhard (*) GnuPG 2.0 ist EOF seit Dezember.
Hallo Roland,
vielen Dank fürs Aufschreiben Deiner Erfahrungen, das bringt uns alle weiter.
Die XMPP Probleme interessieren mich, Du beschreibst aus meiner Sicht zwei verschiedene Probleme
Am Sonntag 21 Januar 2018 11:15:37 schrieb Roland Hummel:
Vorher hatten wir XMPP (Prosody) lange im Test, die Client-Lage unter iOS war aber mehr als dürfitg (nicht in Bezug darauf, dass es für iOS keine XMPP-Clients gibt, sondern,
a) Kannst Du das näher erklären? Es scheint ja welche zu geben, die in Deinem Test durchgefallen sind.
https://xmpp.org/software/clients.html listet vier iOS Klienten, davon erscheinen mindestens die folgenden eine Erstprüfung auf Freie Software zu bestehen:
https://github.com/ChatSecure/ChatSecure-iOS oder eine Variante https://github.com/zom/Zom-iOS https://tigase.tech/projects/tigase-ios-messenger/repository
dass diese spätestens in MUCs große Probleme gemacht haben, entweder weil der OMEMO-Schlüsselaustausch nicht funktionierte oder weil Nachrichten nicht durchkamen).
Das scheinen dann Implementierungsprobleme der XMPP Klienten auf iOS zu sein, richtig? Da XMPP sonst interessant erscheint (weil standardisierte Protokollvarianten), würden sich vielleicht Problemberichte lohnen.
Auch unabhängig von der iOS-Problematik kamen bei XMPP immer mal wieder nicht reproduzierbar Nachrichten nicht an und die Fehlermeldungen waren nicht eindeutig (also: Fehlermeldung, dass eine Nachricht nicht übermittelt wurde, sie kam aber an - keine Fehlermeldung, wenn eine Nachricht angeblich übermittelt wurde, die aber nie ankam).
Das wäre dann allgemeine XMPP Probleme mit den Protokollvarianten oder denkst Du das es dabei auch um die Server-Implementation geht?
Gruß, Bernhard
Mein Kollege spricht von hohen Akkuverbrauch von Conversations, was ich aber nicht bestätigen kann.
Was mich stört ist das Verhalten bei mehreren Geräten. Ich Empfang auf allen Geräten, und ich glaube sogar nur wenn sie Online sind, was mein Gesprächspartner geschrieben hat, aber nicht was ich geschrieben habe.
Naja, nach der Empfehlung hier werde ich wohl mal riot.im testen
Am 24. Januar 2018 08:48:50 MEZ schrieb Bernhard Reiter bernhard@intevation.de:
Hallo Roland,
vielen Dank fürs Aufschreiben Deiner Erfahrungen, das bringt uns alle weiter.
Die XMPP Probleme interessieren mich, Du beschreibst aus meiner Sicht zwei verschiedene Probleme
Am Sonntag 21 Januar 2018 11:15:37 schrieb Roland Hummel:
Vorher hatten wir XMPP (Prosody) lange im Test, die Client-Lage unter iOS war aber mehr als dürfitg (nicht in Bezug darauf, dass es für iOS keine XMPP-Clients gibt, sondern,
a) Kannst Du das näher erklären? Es scheint ja welche zu geben, die in Deinem Test durchgefallen sind.
https://xmpp.org/software/clients.html listet vier iOS Klienten, davon erscheinen mindestens die folgenden eine Erstprüfung auf Freie Software zu bestehen:
https://github.com/ChatSecure/ChatSecure-iOS oder eine Variante https://github.com/zom/Zom-iOS https://tigase.tech/projects/tigase-ios-messenger/repository
dass diese spätestens in MUCs große Probleme gemacht haben, entweder weil der OMEMO-Schlüsselaustausch
nicht
funktionierte oder weil Nachrichten nicht durchkamen).
Das scheinen dann Implementierungsprobleme der XMPP Klienten auf iOS zu sein, richtig? Da XMPP sonst interessant erscheint (weil standardisierte Protokollvarianten), würden sich vielleicht Problemberichte lohnen.
Auch unabhängig von der iOS-Problematik kamen bei XMPP immer mal
wieder
nicht reproduzierbar Nachrichten nicht an und die Fehlermeldungen
waren
nicht eindeutig (also: Fehlermeldung, dass eine Nachricht nicht übermittelt wurde, sie kam aber an - keine Fehlermeldung, wenn eine Nachricht angeblich übermittelt wurde, die aber nie ankam).
Das wäre dann allgemeine XMPP Probleme mit den Protokollvarianten oder denkst Du das es dabei auch um die Server-Implementation geht?
Gruß, Bernhard
-- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
On 01/26/2018 11:25 AM, JokerGermany wrote:
Mein Kollege spricht von hohen Akkuverbrauch von Conversations, was ich aber nicht bestätigen kann.
Ist bei der F-Droid-Version definitiv so, da die App ja nicht von Push profitieren (und deswegen "schlafen" kann), sondern aktiv pullen muss.
Was mich stört ist das Verhalten bei mehreren Geräten. Ich Empfang auf allen Geräten, und ich glaube sogar nur wenn sie Online sind, was mein Gesprächspartner geschrieben hat, aber nicht was ich geschrieben habe.
Deckt sich mit meiner Erfahrungen. Genau solche Punkte wurden mir irgendwann, bei aller Liebe für "Kommandozeilenausflüge", zu "frickelig".
Gruß Roland
On 26.01.2018 14:05, Roland Hummel wrote:
On 01/26/2018 11:25 AM, JokerGermany wrote:
Mein Kollege spricht von hohen Akkuverbrauch von Conversations, was ich aber nicht bestätigen kann.
Ist bei der F-Droid-Version definitiv so, da die App ja nicht von Push profitieren (und deswegen "schlafen" kann), sondern aktiv pullen muss.
Bin mir ziemlich sicher, dass der Akkuverbrauch von Conversations auch ohne Google Play Services kaum ins Gewicht fällt. Mein Handy ist leider grade am Ladegerät und voll geladen und ich sehe deshalb den Akkuverbrauch pro App nicht. Meine aber mich zu erinnern, dass Conversations hinter Screen, OS, WLAN und noch anderem Kram kam.
Grüße David
Am Freitag, 26. Januar 2018, 14:10:54 CET schrieb David Rabel:
Bin mir ziemlich sicher, dass der Akkuverbrauch von Conversations auch ohne Google Play Services kaum ins Gewicht fällt.
Dem ist definitiv so. Conversations baut eine TCP-Verbindung auf und sofern das jeweilige Android-Betriebssystem es zulässt, bleibt diese Verbindung bestehen. Strombedarf fällt dann nur an, wenn auch wirklich Nachrichten verschickt werden und mittels Client State Indication können „unwichtige“ Nachrichten serverseitig herausgefiltert werden, wie etwa: der Client befindet sich im Standby und daher werden keine Nachrichten wie „Nutzer xy schreibt gerade…“ und „Nutzer xy ist jetzt online“ gar nicht erst zugestellt.
Im Gegensatz dazu bietet Matrix nicht diese Möglichkeit, eine persistente TCP- Verbindung zum Server offen zu lassen, so dass natürlich ohne Google-Cloud- Messaging nur noch das aktive Polling bleibt…
Freundliche Grüße, Benedikt Geißler
Am Freitag, 26. Januar 2018, 14:05:51 CET schrieb Roland Hummel:
Ist bei der F-Droid-Version definitiv so, da die App ja nicht von Push profitieren (und deswegen "schlafen" kann), sondern aktiv pullen muss.
Wie ich in der Mail um 14:44 Uhr schrieb, ist das bei Conversations (eigentlich bei jedem XMPP-Client, da das Protokoll ein Push- und kein Pull- Modell vorsieht) nicht so. Es wird nichts aktiv gepullt, nur eine TCP- Verbindung offengehalten. Da das Offenhalten einer Verbindung quasi keinen Strom braucht (zumindest i. d. R. bei WLAN, in Mobilfunknetzen ist das möglicherweise anders), spielt es keine Rolle, ob die Signalisierung nun per Google-Cloud-Messaging oder direkt geschieht. Google-Cloud-Messaging müsste ja auch über eine solche „Standleitung“ realisiert sein.
Freundliche Grüße, Benedikt
# Benedikt Geißler [2018-01-26 16:27 +0100]:
Am Freitag, 26. Januar 2018, 14:05:51 CET schrieb Roland Hummel:
Ist bei der F-Droid-Version definitiv so, da die App ja nicht von Push profitieren (und deswegen "schlafen" kann), sondern aktiv pullen muss.
Wie ich in der Mail um 14:44 Uhr schrieb, ist das bei Conversations (eigentlich bei jedem XMPP-Client, da das Protokoll ein Push- und kein Pull- Modell vorsieht) nicht so. Es wird nichts aktiv gepullt, nur eine TCP- Verbindung offengehalten. Da das Offenhalten einer Verbindung quasi keinen Strom braucht (zumindest i. d. R. bei WLAN, in Mobilfunknetzen ist das möglicherweise anders), spielt es keine Rolle, ob die Signalisierung nun per Google-Cloud-Messaging oder direkt geschieht. Google-Cloud-Messaging müsste ja auch über eine solche „Standleitung“ realisiert sein.
Hier liegt glaube ich der Hund begraben: Im WLAN haben die meisten Messaging-Apps keine Probleme, weil die "Standleitungen" zu den Servern nicht limitiert werden. In den Mobilfunknetzen werden die aber nach einigen Sekunden gekappt, wodurch eine neue Verbindung aufgebaut werden muss, was in der Summe den Akkuverbrauch hochschraubt.
Die Nutzung der GCM-Dienste umgeht das Problem anscheinend, da Google mit den Netzbetreibern Vereinbarungen getroffen hat, dass das Timeout-Limit für GCM nicht greift [^1].
Aus eigener Erfahrung scheinen die verschiedenen Apps aber unterschiedlich gute Lösungen dafür zu finden. Telegram hat auch in Mobilfunknetzen einen kaum erhöhten Akkuverbrauch, Conversations, Signal und Wire allerdings gehen teilweise durch die Decke. Von WhatsApp habe ich gehört, dass dieses auch ohne Google-Dienste recht akkuschonend läuft, aber Nachrichten teilweise erst viel zu spät auf dem Telefon eintreffen.
Viele Grüße Max
[^1]: https://github.com/signalapp/Signal-Android/issues/6732#issuecomment-3346057...
Am Sonntag 28 Januar 2018 12:20:45 schrieb Max Mehl:
Die Nutzung der GCM-Dienste umgeht das Problem anscheinend, da Google mit den Netzbetreibern Vereinbarungen getroffen hat, dass das Timeout-Limit für GCM nicht greift [^1].
Aus [^1] wird das nicht ganz klar (zumindest mir beim überfliegen nicht. Das wäre aber interessant, denn wenn das so wäre, dann hätten wir meiner Ansicht nach einen Fall für das Kartellamt: Google starke Android Marktstellung wird verwendet, um in anderen Bereichen - "Messenger" - Mitbewerber zu behindern. Und einen politischen Fall hätten wir auch für die Netzneutralität. Deswegen scheint mir das unwahrscheinlich. Blackberry hatte angeblich mal gute weltweite Verträge für seinen Nachrichtendienst, auch Nokia hatte gute Verbindungen zu den Carriern. Aber Google ist viel führender.
Aus eigener Erfahrung scheinen die verschiedenen Apps aber unterschiedlich gute Lösungen dafür zu finden. Telegram hat auch in Mobilfunknetzen einen kaum erhöhten Akkuverbrauch, Conversations, Signal und Wire allerdings gehen teilweise durch die Decke. Von WhatsApp habe ich gehört, dass dieses auch ohne Google-Dienste recht akkuschonend läuft, aber Nachrichten teilweise erst viel zu spät auf dem Telefon eintreffen.
Auch das spricht eher dafür, dass es ein anderes technisches Problem ist. Dann wäre es aber für jeden Mitbewerber interessant, wie das zu lösen ist.
[^1]:
https://github.com/signalapp/Signal-Android/issues/6732#issuecomment-3346057...
Am Freitag, 26. Januar 2018, 11:25:44 CET schrieb JokerGermany:
Mein Kollege spricht von hohen Akkuverbrauch von Conversations, was ich aber nicht bestätigen kann.
Ist er in vielen Gruppenchats beteiligt (also welchen mit höherem Nachrichtenaufkommen)? Und hat der Server Stream Management und Client State Indication aktiviert? Wenn ersteres und/oder nicht zweites der Fall ist, dann könnte das der Grund sein. ;)
Weitere Details gibt es auch in diesem Beitrag: https://gultsch.de/xmpp_2016.html
Ich Empfang auf allen Geräten, und ich glaube sogar nur wenn sie Online sind, was mein Gesprächspartner geschrieben hat, aber nicht was ich geschrieben habe.
Hat der Server Message Carboning aktiviert? Wenn nein, dann empfängt immer nur das Gerät, welches online ist und höchste Prorität eingestellt hat, die Nachricht.
Benutzt du OMEMO oder OTR?
Bei OMEMO: stelle sicher, dass du auch allen deinen eigenen Schlüsseln vertraust, dann müsstest du auch alle Nachrichten bekommen. Evtl. hilfreich ist auch „Blind Trust Before Verification“ bei Conversations: https://gultsch.de/trust.html
Bei OTR: Da kann ich ohnehin nur von abraten, da es nicht mit Message Carboning und Message Archive Management zusammenarbeitet. Bei Conversations wird es perspektivisch bald auch Gott sei Dank nicht mehr angeboten.
Freundliche Grüße, Benedikt Geißler
Am 26.01.2018 um 14:12 schrieb Benedikt Geißler:
Am Freitag, 26. Januar 2018, 11:25:44 CET schrieb JokerGermany:
Mein Kollege spricht von hohen Akkuverbrauch von Conversations, was ich aber nicht bestätigen kann.
Ist er in vielen Gruppenchats beteiligt (also welchen mit höherem Nachrichtenaufkommen)? Und hat der Server Stream Management und Client State Indication aktiviert? Wenn ersteres und/oder nicht zweites der Fall ist, dann könnte das der Grund sein. ;)
Das mit dem Gruppenchats bezweifle ich, da ich überhaupt der schuldige bin, dass er XMPP nutzt ;)
Ich Empfang auf allen Geräten, und ich glaube sogar nur wenn sie Online sind, was mein Gesprächspartner geschrieben hat, aber nicht was ich geschrieben habe.
Hat der Server Message Carboning aktiviert? Wenn nein, dann empfängt immer nur das Gerät, welches online ist und höchste Prorität eingestellt hat, die Nachricht.
Benutzt du OMEMO oder OTR?
Bei OMEMO: stelle sicher, dass du auch allen deinen eigenen Schlüsseln vertraust, dann müsstest du auch alle Nachrichten bekommen. Evtl. hilfreich ist auch „Blind Trust Before Verification“ bei Conversations: https://gultsch.de/trust.html
Nutze natürlich Omemo. Allen meinen Geräten habe ich nur nicht in gajim getraut, alle anderen haben sich gegenseitig getraut. Habe mal angehängt 3 Bilder eines Chatverlaufs Das Firephone und das VFD1400 waren die ganze Zeit angeschaltet, über das Firephone wurde geschrieben. Das Firephone2 wurde kurz vor 12 Uhr angeschaltet.
Das Gajim auf meinem Rechner, dass nicht an war, findet selbst im Verlauf keine Nachrichten von heute...
Ups vergessen, Als Server wird trashserver.net wird sowohl vom Sender, als auch vom Empfänger verwendet. Den habe ich mir extra danach ausgesucht, ob er "alle" Addons unterstützt
Am 26.01.2018 um 14:59 schrieb JokerGermany:
Am 26.01.2018 um 14:12 schrieb Benedikt Geißler:
Am Freitag, 26. Januar 2018, 11:25:44 CET schrieb JokerGermany:
Mein Kollege spricht von hohen Akkuverbrauch von Conversations, was ich aber nicht bestätigen kann.
Ist er in vielen Gruppenchats beteiligt (also welchen mit höherem Nachrichtenaufkommen)? Und hat der Server Stream Management und Client State Indication aktiviert? Wenn ersteres und/oder nicht zweites der Fall ist, dann könnte das der Grund sein. ;)
Das mit dem Gruppenchats bezweifle ich, da ich überhaupt der schuldige bin, dass er XMPP nutzt ;)
Ich Empfang auf allen Geräten, und ich glaube sogar nur wenn sie Online sind, was mein Gesprächspartner geschrieben hat, aber nicht was ich geschrieben habe.
Hat der Server Message Carboning aktiviert? Wenn nein, dann empfängt immer nur das Gerät, welches online ist und höchste Prorität eingestellt hat, die Nachricht.
Benutzt du OMEMO oder OTR?
Bei OMEMO: stelle sicher, dass du auch allen deinen eigenen Schlüsseln vertraust, dann müsstest du auch alle Nachrichten bekommen. Evtl. hilfreich ist auch „Blind Trust Before Verification“ bei Conversations: https://gultsch.de/trust.html
Nutze natürlich Omemo. Allen meinen Geräten habe ich nur nicht in gajim getraut, alle anderen haben sich gegenseitig getraut. Habe mal angehängt 3 Bilder eines Chatverlaufs Das Firephone und das VFD1400 waren die ganze Zeit angeschaltet, über das Firephone wurde geschrieben. Das Firephone2 wurde kurz vor 12 Uhr angeschaltet.
Das Gajim auf meinem Rechner, dass nicht an war, findet selbst im Verlauf keine Nachrichten von heute...
Hi,
On 01/26/2018 04:27 PM, Benedikt Geißler wrote:
Wie ich in der Mail um 14:44 Uhr schrieb, ist das bei Conversations (eigentlich bei jedem XMPP-Client, da das Protokoll ein Push- und kein
Pull-
Modell vorsieht) nicht so. Es wird nichts aktiv gepullt, nur eine TCP- Verbindung offengehalten. Da das Offenhalten einer Verbindung quasi
keinen
Strom braucht (zumindest i. d. R. bei WLAN, in Mobilfunknetzen ist das möglicherweise anders), spielt es keine Rolle, ob die Signalisierung
nun per
Google-Cloud-Messaging oder direkt geschieht. Google-Cloud-Messaging
müsste ja
auch über eine solche „Standleitung“ realisiert sein.
okay, vielen Dank für die technische Richtigstellung. Dennoch wurde sich seitens meiner Tester*innen hier und da massiv über den hohen Akkuverbrauch durch Conversations beschwert, den ich dann (wie sich nun herausstellt leider falsch) mit dem Pull-Verfahren erklärt hatte. Anyway: auch mit falscher Erklärung gehörte ein hoher Energie-Verbrauch ausdrücklich nicht zu den Argumenten, die ich in solchen Fällen gegen XMPP angeführt hätte. Wenn ich zivilgesellschaftlich kontrollierbare IT-Strukturen mit erhöhtem Energieverbrauch bezahlen muss, dann zahle ich diesen Preis gerne (Stallmans "zero practical sacrifice"-Argument: wenn Freiheit nichts kostet, ist Freiheit auch nichts wert - mit diesem Argument habe ich die meisten "meiner" User auch überzeugt, XMPP doch bitte weiter eine Chance zu geben). Soll heißen: Das mit dem Akkuverbrauch ist für mich nicht auf der Argumentationsliste, weder bei Matrix noch bei XMPP. Wahrscheinlich hab ich mich deswegen auch weniger mit den technischen Details auseinandergesetzt.
Unterm Strich zählte für mich: bei Matrix kamen ausnahmslos immer alle Nachrichten auf allen Geräten plattformübergreifend an, inklusive vollständiger History auf allen Geräten (egal wie lange einige davon abgeschaltet waren) und ohne überall nochmal MUCs hinzuzufügen und Einstellungen vornehmen zu müssen und zuguterletzt: ohne irgendwelche Compliance-Tests durchführen zu müssen oder nächtelanges "welche XEP-Erweiterung sollte ich wohl noch installieren, damit ich endlich zuverlässige Nachrichtenübermittlung bekomme"-Getüftel und Hilfe-Bettelei in Dev-Chats.
Das Problem ist nämlich: ist der mühsam von XMPP überzeugten Freund*innen-Kreis auch nur einmal von der Problematik betroffen, dass irgendwas nicht ankam (was btw in Diskussionen im Schlimmsten Fall zu immensen Missverständnissen führen kann), ist das Vertrauen in das System dahin, was sich darin zeigt, dass mir Leute, die mir über XMPP schreiben könnten, dann im Notfall doch eine SMS schicken, weil sie nicht mehr auf XMPP vertrauen.
In einem MUC, den ich seit Deaktivierung meines eigenen Prosody-Servers über einen riseup-Account nutze, hat sich das Problem bestätigt: dort sind dismail.de-User, jabber.at-User und riseup.net-User anwesend und auch hier kommen immer wieder Zwischenfragen, dass der Chatverlauf für User X irgendwie keinen Sinn macht mit der Bitte, doch mal einen Screenshot aus der Sicht von User Y zu schicken um zu sehen, was da schon wieder nicht durchkam.
Ich sage das nicht, weil ich frustriert auf einem alt-ehrwürdigen Standard wie XMPP rumbashen will, sondern weil ich es wirklich schade finde, dass XMPP trotz seiner über Jahre vorhandenen Führungs-Position im Bereich dezentraler Messenger-Systeme es nicht geschafft hat, ein System wie Matrix bereitzustellen, mit dem auch Leute mit begrenzten zeitlichen Möglichkeiten und begrenztem IT-Wissen das ja ursprünglich wohl angestrebte Ziel eines breiten föderalen Netzwerkes herstellen können, 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 Elite ist, womit das (für mich) eigentliche Ziel verfehlt wird, eine digital mündige Zivilgesellschaft realistisch zu ermöglichen.
Aber wie gesagt: ist ja dank Bridging durch Matrix kein Problem. Je mehr dezentrale Systeme es gibt, desto besser. Ich bin aber froh, dass mit Matrix die große Lücke gefüllt wird, auch technisch interessierten Laien wie mir selbstverwaltete digitale Infrastrukturen zu ermöglichen.
On 01/26/2018 02:30 PM, Alexander Dahl wrote:
Unterstützt Dein XMPP-Server XEP-0280 Message Carbons? Wenn nicht, ist das vielleicht der Grund dafür.
War zumindest bei mir (Prosody) aktiviert, die beschriebenen Probleme gab es trotzdem.
On 01/26/2018 03:02 PM, JokerGermany wrote:
Nutze natürlich Omemo. Allen meinen Geräten habe ich nur nicht in gajim getraut, alle anderen haben sich gegenseitig getraut. Habe mal angehängt 3 Bilder eines Chatverlaufs Das Firephone und das VFD1400 waren die ganze Zeit angeschaltet, über das Firephone wurde geschrieben. Das Firephone2 wurde kurz vor 12 Uhr angeschaltet.
Das Gajim auf meinem Rechner, dass nicht an war, findet selbst im Verlauf keine Nachrichten von heute...
Perfekt beschrieben, genau diese Art von Problemen kann ich vielfach bestätigen.
Gruß und Danke für den Austausch Roland
Für mich hört sich "Nachrichten kommen an eigenen (oder anderen einzelnen) Geräten nicht an" nach OMEMO falsch konfiguriert an. Tritt das Problem auch ohne OMEMO auf? Falls nein, wird unter Kontoeinstellungen in Conversations (bzw an der entsprechenden Stelle in anderen Clients) den anderen eigenen Clients vertraut? Probleme mit XMPP hatte ich bisher nur mit ejabberd 17.08, der s2s Verbindungen immer wieder bis zum Neustart verloren hat (ich habe ihn deswegen schon Windows getauft), und durch falsch konfiguriertes OMEMO. Aus u.a. diesem Grund möchte Holger auch OpenPGP für XMPP etablieren (den neueren Standard, XEP-0373).
Gruß
Ferdinand
Hi Roland,
Am Freitag 26 Januar 2018 17:26:26 schrieb Roland Hummel:
Ich sage das nicht, weil ich frustriert auf einem alt-ehrwürdigen Standard wie XMPP rumbashen will, sondern weil ich es wirklich schade finde, dass XMPP trotz seiner über Jahre vorhandenen Führungs-Position im Bereich dezentraler Messenger-Systeme es nicht geschafft hat, ein System wie Matrix bereitzustellen, mit dem auch Leute mit begrenzten zeitlichen Möglichkeiten und begrenztem IT-Wissen das ja ursprünglich wohl angestrebte Ziel eines breiten föderalen Netzwerkes herstellen können, das dann auch wirklich zuverlässig funktioniert.
deshalb finde ich es so interessant mehr darüber zu wissen, wo das eigentliche Problem liegt. Deshalb erneut Danke fürs Ausschreiben. Es geht mir auch so, dass ich nur IT empfehlen mag, welche auch für die Leute selbstständig geht. Da ist propietäre Software oft weit überlegen, leider. :( (Selbstverständlich empfehle ich jedem Schritte in Richtung Freie Software zu unternehmen, die fallen je nach Person und Lage nur sehr anders aus.)
Zurück zur XMPP Zuverlässigkeit: Es macht einen großen Unterschied aus, ob das Problem wirklich das konzeptuelle Protokoll ist oder die Implementierungen davon. Oder ob es eher ein Kompatibilitätsproblem ist. Und oft ist es auch eine Frage von Fleißarbeit die Software-Entwicklung gut genug durchführen zu können, mit nötiger Dokumentation, Paketierungen und etwas Support.
Aus meiner Sicht ist es auch wichtig, dass wir verstehen, dass wir als Nutzer den Leuten oder Gruppen genug finanzielle Mittel zur Verfügung stellen, damit sie das alles professional machen können. Wir müssen deshalb jeweils nach dem Geschäftsmodell fragen und welche für Freie Software ermöglichen. (Mit meinem Unternehmen Intevation bin ich auch nach vielen Jahren auf der Suche nach Geschäftsideen, welche mir ermöglichen für die Nutzenden gute IT zu machen. In manchen Bereichen ist das sehr schwer, bis unmöglich.)
Gruß, Bernhard
Hi Bernhard,
On 01/29/2018 09:39 AM, Bernhard E. Reiter wrote:
Zurück zur XMPP Zuverlässigkeit: Es macht einen großen Unterschied aus, ob das Problem wirklich das konzeptuelle Protokoll ist oder die Implementierungen davon. Oder ob es eher ein Kompatibilitätsproblem ist.
Dazu bin ich leider kaum aussagefährig, allerdings glaube ich mich zu erinnern, dass im Prosody-Dev-MUC mal gesagt wurde, dass ein XMPP-User, der offline ist, für den Server nicht existiert. Das wäre zum Beispiel ein Punkt, bei dem ich mir vorstellen könnte, dass er Zustellungsprobleme verursacht. Sicher alles historisch bedingt, aber trotzdem ein Problem (wenn es stimmt).
Und oft ist es auch eine Frage von Fleißarbeit die Software-Entwicklung gut genug durchführen zu können, mit nötiger Dokumentation, Paketierungen und etwas Support.
Da muss ich sagen finde ich Prosody und Matrix/Riot gleichermaßen mäßig. Bei beiden gibt es kein Forum, was bedeutet: jeder Anfänger fragt immer wieder die gleichen Dinge und wartet bettelnd auf Antwort in irgendeinem Dev-Chat. Das Problem fällt bei Matrix nur geringer aus, weil es selten zu Problemen kommt und die GitHub-Seite mittlerweile auch als Forum missbraucht wird. Ich weiß nicht, warum sich Devs sowas antun (aber wie gesagt: ich bin auch keiner). Ich weiß nur, dass bei Seafile das Community-Forum eine astreine Knowledge Base abgibt (neben einer sehr guten Doku), bei der man zu jedem Problem etwas findet und ab und an helfen sogar die Devs bei Problemen mit der Community-Version. Es geht also auch anders.
Aus meiner Sicht ist es auch wichtig, dass wir verstehen, dass wir als Nutzer den Leuten oder Gruppen genug finanzielle Mittel zur Verfügung stellen, damit sie das alles professional machen können. Wir müssen deshalb jeweils nach dem Geschäftsmodell fragen und welche für Freie Software ermöglichen. (Mit meinem Unternehmen Intevation bin ich auch nach vielen Jahren auf der Suche nach Geschäftsideen, welche mir ermöglichen für die Nutzenden gute IT zu machen. In manchen Bereichen ist das sehr schwer, bis unmöglich.)
Selbstredend. Ich vertrete hier eine 1€-Philosophie: 1€ für täglich genutzte Freie Software pro Monat tun nicht weh, machen aber in der Masse an Usern sicher genug aus, um damit ein kleines Team zu finanzieren. Die Devs von Prosody zB nehmen aber keine Spenden, die von Seafile bspw. auch nicht, warum auch immer. Seafile finanziert sich über eine Pro-Version, bei Prosody weiß ich es nicht genau. Bei Matrix habe ich den Haupt-Entwickler angeschrieben, um Kontodaten gebeten und hatte einen Tag später eine Antwort.
Gruß Roland
Hallo Roland,
Am Donnerstag 01 Februar 2018 23:56:08 schrieb Roland Hummel:
allerdings glaube ich mich zu erinnern, dass im Prosody-Dev-MUC mal gesagt wurde, dass ein XMPP-User, der offline ist, für den Server nicht existiert. Das wäre zum Beispiel ein Punkt, bei dem ich mir vorstellen könnte, dass er Zustellungsprobleme verursacht. Sicher alles historisch bedingt, aber trotzdem ein Problem (wenn es stimmt).
klingt zumindest konzeptuell problematisch: Wenn ein Nutzer offline ist, muss der Server die bisher nicht zugestellen Nachrichten vorhalten.
finde ich Prosody und Matrix/Riot gleichermaßen mäßig. Bei beiden gibt es kein Forum
Ein Forum zu betreiben und zu betreuen kann durchaus Arbeit machen. Das von Dir als gutes Beispiel angeführte Seafile nutzt die Software Discourse und scheint ein Freemium-Geschäftsmodell zu haben.
Selbstredend. Ich vertrete hier eine 1€-Philosophie: 1€ für täglich genutzte Freie Software pro Monat tun nicht weh, machen aber in der Masse an Usern sicher genug aus, um damit ein kleines Team zu finanzieren.
Das ist eine vorbildliche Einstellung. Wir bei Intevation bezahlen freiwillig etwa 1% des bereinigten Umsatzes an die Freie Software-Initiativen deren Produkte wir in Aufträgen oder für uns selbst nutzen.
Die Devs von Prosody zB nehmen aber keine Spenden, die von Seafile bspw. auch nicht, warum auch immer.
Auch hier ist es bestimmt der Aufwand und das Problem, dass es kaum einfache Zahlungssysteme für kleinere Zahlungen gibt. Paypal ist relativ teuer und flattr hat sich von den Kleinzahlungen weg hin zu bezahle für Webinhalte per Browser-Add-on entwickelt.
Viele Grüße, Bernhard
Hallo,
Am Tue, 6 Feb 2018 17:13:39 +0100 schrieb "Bernhard E. Reiter" bernhard@fsfe.org:
Die Devs von Prosody zB nehmen aber keine Spenden, die von Seafile bspw. auch nicht, warum auch immer.
Auch hier ist es bestimmt der Aufwand und das Problem, dass es kaum einfache Zahlungssysteme für kleinere Zahlungen gibt. Paypal ist relativ teuer und flattr hat sich von den Kleinzahlungen weg hin zu bezahle für Webinhalte per Browser-Add-on entwickelt.
"liberapay" [1] sieht für mich wie eine geeignete Plattform für die (regelmäßige) Unterstützung von Entwicklern und Projekten aus. Die Plattform wird von einer gemeinnützigen Organisation betrieben und läuft auf freier Software.
Lars
Lars,
Am Mittwoch 07 Februar 2018 00:32:51 schrieb Lars Kruse:
"liberapay" [1] sieht für mich wie eine geeignete Plattform für die (regelmäßige) Unterstützung von Entwicklern und Projekten aus. [1] https://liberapay.com/
Danke sehr für den Hinweis!
Die Plattform wird von einer gemeinnützigen Organisation betrieben und läuft auf freier Software.
Beides sind wir mich tendenziell eher kleine Nachteile, weil langfristig lebensfähige Organisationen wirtschaftlich arbeiten müssen und das ehrenamtliche Engagement hat da erhöhte Risiken birgt, die kritische Masse nicht zu erreichen. Leider gilt das gleiche für die Software für Zahlungssysteme, mir wäre wichtig, dass es sehr zuverlässig, umweltfreundlich und dauerhaft funktionieren. Da denke ich eher an Banken, am besten staatliche Banken und ein Einbauen in deren Systeme. Die sind aber (leider, meiner Kenntnis nach) noch nicht auf Freie Software.
In jedem Fall: Gut, dass es liberapay gibt, ich wünsche Ihnen viel Erfolg und werde den auch fördern!
Viele Grüße, Bernhard
On 09.03.2018 11:18, Bernhard Reiter wrote:
Die Plattform wird von einer gemeinnützigen Organisation betrieben und läuft auf freier Software.
Beides sind wir mich tendenziell eher kleine Nachteile, weil langfristig lebensfähige Organisationen wirtschaftlich arbeiten müssen und das ehrenamtliche Engagement hat da erhöhte Risiken birgt,
"Gemeinnützig" heißt nicht Ehrenamt. Freie Software heißt nicht "kein Geschäftsmodell".
Grüße aus einer gemeinnützigen GmbH mit 10 Angestellten. ;-)
-- Moritz
On 10.03.2018 11:38, Moritz Bartl wrote:
Die Plattform wird von einer gemeinnützigen Organisation betrieben und läuft auf freier Software.
Beides sind wir mich tendenziell eher kleine Nachteile, weil langfristig lebensfähige Organisationen wirtschaftlich arbeiten müssen und das ehrenamtliche Engagement hat da erhöhte Risiken birgt,
"Gemeinnützig" heißt nicht Ehrenamt. Freie Software heißt nicht "kein Geschäftsmodell".
Dazu hatte ich jetzt noch eine nette Diskussion off-list. Ich möchte euch einen Teil meiner Antwort nicht vorenthalten. Meiner Meinung nach passt das sehr gut hier hin, das Thema Gemeinnützigkeit, insbesondere mit Bezug auf die Entwicklung von Freier Software.
"Gemeinnützig" heißt nicht Ehrenamt.
Eigentlich schon. Ausnahmen sind nur insoweit möglich, wie die Satzung des Vereins es explizit vorsieht. :-)
Nein.
Erstmal, "Gemeinnützig" heißt nicht gleich Verein.
Im ursprünglichen Text war sogar von einer "non-profit" die Rede, das dann einfach 1:1 auf "gemeinnützig" UND dann noch "Verein" zu mappen ist falsch. Im englischen Sprachraum spricht man oft zur Unterscheidung von "charity" vs "non-profit".
Das Beispiel der gemeinnützigen GmbH habe ich gegeben, da gibt es keine vorgeschriebenen Ehrenämter. Genausowenig z.B. in der gemeinnützigen AG.
Zweitens: Die Vorstandsämter in gemeinnützigen _Vereinen_ dürfen üblicherweise nicht vergütet werden, das ist richtig. Wenn man das anders handhaben will braucht es eine Satzungsänderung -- die ja aber auch kein großes Thema sein sollte.
Aber: Auch ohne besondere Regelung ist das Bezahlen von Arbeit ganz regulär möglich, sogar wenn es die selben Personen sind. Wir haben das bei einem Verein so, da ist jemand ehrenamtlich Vorstand und gleichzeitig auch (bezahlt) Projektleiter. In der _Rolle_ des Vorstands darf er nicht vergütet werden. Für andere Tätigkeiten eben schon.
Neben der "ganz normalen" Bezahlung von Mitarbeitern, die _nicht_ eingeschränkt ist, gibt es bei gemeinnützigen Organisationen noch steuerlich begünstigte Aufwandsentschädigungen und Ehrenamtsfreibeträge.
http://www.vereinsbesteuerung.info/leitfaden_lst.htm http://www.iww.de/vb/archiv/vereinsvorstand-die-hauptamtliche-vereinsfuehrun...
Um auf das ursprüngliche Thema zurückzukommen: Da würde es ja um z.B. die Bezahlung von (Programmier-)Arbeit an Open Source gehen, was sich ganz klar von den Vorstandsämtern unterscheidet, und somit völlig unproblematisch auch mit der Standardregelung in Satzungen machbar ist. Selbst wenn der Vorstandsvorsitzende Hans Meier die selbe Person wie der Programmierer Hans Meier ist.
Genau da sehe ich das Problem: Nenne mir mal bitte einen zur Gemeinnützigkeit fähigen (Vereins)Zweck nach § 42 AO, der ´ Auftragsprogrammierung als reguläre Tätigkeit der Organisation (nicht nur zu administrativen Hilfszwecken) zulässt. Denn nur dafür ("…ausschließlich satzungsgemäße Zwecke…") darf die gemeinnützige Organisation ja Mittel aufwenden.
Es gibt verschiedene Trägerorganisationen von Open Source-Projekten, die auch Entwicklertätigkeit vergüten, im Rahmen ihrer ideellen Tätigkeiten oder im Zweckbetrieb.
Allein schon die reine Hilfsarbeit für administrative Zwecke hebelt dein Argument "alles bei gemeinnützigen Organisationen passiert ehrenamtlich" aus. Weil dann bezahlt man halt so mal jemanden für seine ganze Arbeit, die ja nicht unbeträchtlich sein kann. Bei Vereinen wird das ja üblicherweise noch nichtmal nach "Hilfstätigkeit" groß aufgeschlüsselt. Ich erlebe das oft, dass diese pauschale Aussage "nur Ehrenamt" verhindert, dass jemand z.B. für seine "Devops" nicht bezahlt wird, weil man gar nicht daran denkt dass der ja einfach mal ne Rechnung stellen könnte.
Hier die Satzung unserer gGmbH: https://gitlab.techcultivation.org/techcultivation/bylaws
Die ist noch zu frisch, um mein Argument zu zementieren, aber immerhin nicht nur vorläufig anerkannt (Gründung 2016) und expliziter Bezug auf Freie Software. Wir nehmen u.a. an einem Horizon 2020-Forschungsprojekt teil, was sich allein schon recht klar auf "Wissenschaft und Forschung" nach AO §52(2)1 mappen lässt.
In unserem anderen Verein lassen wir schon lange Open Source Software entwickeln, dort mappen wir das (erfolgreich; schon einige Jahre, inkl Betriebsprüfung etc alles durch) auf AO §52(2)24 "allgemeine Förderung des demokratischen Staatswesens".
Generisch oft erfolgreich argumentieren lässt sich schon alleine der typische AO §52(2)7 der Volksbildung. Wir bauen ja nicht nur "Open Source Software", sondern es geht um die Veröffentlichung von Quellcode und zugehörige Bildungsveranstaltungen. Diese Bildungsveranstaltungen müssen mit der entsprechenden Softwareentwicklung nicht nur vorbereitet und somit ermöglicht werden, sondern es wird Quellcode zur Wiederverwendung und zur Erlernung von Programmierfähigkeiten online gestellt und durch Bug Tracker, Mailinglisten und IRC-Channels ja auch noch öffentliche Foren zur Diskussion bereitgestellt, die sozusagen dauerhafte Präsenz von Bildungsveranstaltungen im digitalen Äquivalent zu einem Vereinsheim.
Und dann hat man natürlich noch einen Hebel über die Software selbst, also dessen Einsatzzweck. Darüber lässt sich in vielen Fällen alleine schon eine Argumentation aufbauen, dass durch die Entwicklung dieser gemeinnützige Zwecke erfüllt werden. Zum Beispiel die "Förderung demokratischen Staatswesens", so wie wir das mit Krypto- und Anonymisierungstools machen. Das kann aber auch "Förderung von Kunst und Kultur" (§52(2)7) und jede andere Kategorie der Abgabenordnung sein, je nachdem wo das Projekt eben reinpasst.
Daraus ergibt sich eine interessante Möglichkeit, die meiner Meinung nach noch viel zu selten genutzt wird: Die Vergabe von (steuerfreien) Stipendien zur Entwicklung von freien Technologien.
Ein anderes Beispiel ist der Open Knowledge Foundation Deutschland e.V., die sowohl Entwickler bezahlt als auch Träger des Prototype Fund ist, der, zwar indirekt aber dennoch, auch Arbeit an Freier Software bezahlt (und seine Mitarbeiter). Da wir nicht auf den deutschen Sprachraum limitiert sind (LiberaPay ist in Frankreich), sind die "großen bekannten Beispiele" vermutlich Wikipedia (Wikimedia Foundation) und Firefox+Thunderbird (Mozilla Foundation).
Für mich zumindest ist das ein spannendes Thema, und ich freue mich über jeden mit dem man sich darüber austauschen kann. :-)
Spannend wirds spätestens dann wenn man im Schritt weiter darüber nachdenkt, wie denn Geld dann in einem typischen Projekt überhaupt ausgegeben werden soll. Wer hat die Berechtigung? Wer entscheidet? Will man etwas "klassisch hierarchisches", oder (wie) kann man die freie Zusammenarbeit vieler unabhängiger Akteure überhaupt in die Geldwelt übersetzen? Das ist ein Thema, zu dem ich viel zu wenig finde. Siehe dazu auch mein Vortrag auf dem 34c3: https://fahrplan.events.ccc.de/congress/2017/Fahrplan/events/9087.html .
-- Moritz
Hallo,
Am 2018-03-11 um 10:11 schrieb Moritz Bartl:
Aber: Auch ohne besondere Regelung ist das Bezahlen von Arbeit ganz regulär möglich, sogar wenn es die selben Personen sind. Wir haben das bei einem Verein so, da ist jemand ehrenamtlich Vorstand und gleichzeitig auch (bezahlt) Projektleiter. In der _Rolle_ des Vorstands darf er nicht vergütet werden. Für andere Tätigkeiten eben schon.
für die ganz neugierigen: genau so halten wir es übrigens beim FSFE e.V. auch.
Viele Grüße,
Hi Moritz,
Am Samstag 10 März 2018 11:38:41 schrieb Moritz Bartl:
On 09.03.2018 11:18, Bernhard Reiter wrote:
Die Plattform wird von einer gemeinnützigen Organisation betrieben und läuft auf freier Software.
Beides sind wir mich tendenziell eher kleine Nachteile, weil langfristig lebensfähige Organisationen wirtschaftlich arbeiten müssen und das ehrenamtliche Engagement hat da erhöhte Risiken birgt,
"Gemeinnützig" heißt nicht Ehrenamt. Freie Software heißt nicht "kein Geschäftsmodell".
das ist mir beides bekannt (als Mitgründer der FSFE, die gemeinnützig ist und Vollzeitangestellte hat und als Mitgründer von Intevation die rund 25 Leute beschäftigt und nur Freie Software "macht".)
Was ich sagen wollte ist: ein existierendes, transparentes Geschäftsmodell und eine erkennbare Tendenz zum nachhaltigen wirtschaftlichen Erfolg mit bezahlten Personen ist ein wichtiger Bewertungsfaktor, erst ist in diesem konkreten Fall für mich noch wichtiger als eine Gemeinnützigkeit.
Gruß, Bernhard
Moin,
On Fri, Jan 26, 2018 at 11:25:44AM +0100, JokerGermany wrote:
Was mich stört ist das Verhalten bei mehreren Geräten. Ich Empfang auf allen Geräten, und ich glaube sogar nur wenn sie Online sind, was mein Gesprächspartner geschrieben hat, aber nicht was ich geschrieben habe.
Unterstützt Dein XMPP-Server XEP-0280 Message Carbons? Wenn nicht, ist das vielleicht der Grund dafür.
Schau mal in Conversations unter "Konten verwalten" auf Dein Konto und hake dann in den Optionen "Server-Info" an. Es werden dann eine Auswahl von XEPs angezeigt, die für mobile Nutzung sinnvoll sind, und ob der von Dir genutzte Server die unterstützt.
Ganz interessant zu dem Thema ist auch:
https://conversations.im/compliance/
Inklusive sehr weit untem verlinkten Tool, das die Daten generiert hat, kann man auch ohne in der Liste aufzutauchen mal gegen seinen XMPP-Server fahren. ;-)
Grüße Alex
On 26.01.2018 11:25, JokerGermany wrote:
Naja, nach der Empfehlung hier werde ich wohl mal riot.im testen
Schaue Dir dabei auch die Privacy Policy von riot.im einmal an [1]. Man scheint dort ziemlich viele Daten zu sammeln.
Viele Grüße
Stefan
Hi Stefan,
On 01/27/2018 08:02 AM, Stefan wrote:
Schaue Dir dabei auch die Privacy Policy von riot.im einmal an [1]. Man scheint dort ziemlich viele Daten zu sammeln.
dauz kann ich nur sagen: mich stört das Opt-Out-Verfahren bei Riot auch (sowohl, was das Sammeln standardmäßig aktivierte Sammeln von Nutzungsdaten in Riot und Synapse betrifft als auch den voreingestellten Identitiy-Server in Riot). Allerdings hat mir der Hauptentwickler bspw. innerhalb eines Tages geantwortet, als ich Google Analytics auf der Riot-Webseite bemängelte, wodurch ich erfuhr, dass zumindest alles derartige auf Piwik umgestellt werden soll, was mittlerweile auch geschehen ist. Das löst das Opt-Out-Problem nicht, aber zumindest gibt es Opt-Out.
Für mich bleibt unterm Strich dann nur Matrix oder XMPP - und XMPP funktionierte, zumindest in meinem Testrahmen, plattformübergreifend nicht zuverlässig.
In diesem Zusammenhang halte ich das Opt-Out-Verfahren für Nutzungsdaten durch Riot als Client und Synapse als Server sowie in Bezug auf den Identity-Server, den man beim Anmelden in Riot halt austragen muss, für akzeptabel, wenn ich dafür eine föderalen Freien Messenger bekomme, dessen Server sich auch für Laien an einem Nachmittag einrichten lässt.
Gruß Roland
Hallo Roland!
On 29.01.2018 16:07, Roland Hummel wrote:
Hi Stefan,
On 01/27/2018 08:02 AM, Stefan wrote:
Schaue Dir dabei auch die Privacy Policy von riot.im einmal an [1]. Man scheint dort ziemlich viele Daten zu sammeln.
dauz kann ich nur sagen: mich stört das Opt-Out-Verfahren bei Riot auch (sowohl, was das Sammeln standardmäßig aktivierte Sammeln von Nutzungsdaten in Riot und Synapse betrifft als auch den voreingestellten Identitiy-Server in Riot). Allerdings hat mir der Hauptentwickler bspw. innerhalb eines Tages geantwortet, als ich Google Analytics auf der Riot-Webseite bemängelte, wodurch ich erfuhr, dass zumindest alles derartige auf Piwik umgestellt werden soll, was mittlerweile auch geschehen ist. Das löst das Opt-Out-Problem nicht, aber zumindest gibt es Opt-Out.
Wo finde ich denn eine entsprechende Opt-Out-Einstellung? Bisher habe ich die Einstellung irgendwie übersehen.
Viele Grüße
Stefan
Hi Stefan,
On 01/29/2018 08:58 PM, Stefan wrote:
Wo finde ich denn eine entsprechende Opt-Out-Einstellung? Bisher habe ich die Einstellung irgendwie übersehen.
1. Den Identity-Server kannst Du nur beim Anmelden ändern: Option "Benutzerdefinierter Server" anzeigen lassen -> "Identitätsserver (vorhandenen Eintrag löschen, falls es eine Fehlermeldung gibt, lediglich "https:" eintragen - den Bug habe ich bereits gemeldet)
2. "Anonymisierte Analysedaten" im Client deaktivieren geht zu meinem Erstaunen nur über den Desktop-Client bzw. die WebApp, ich konnte die Funktion in der Android-App (F-Droid) nicht finden, die Einstellung sollte aber, wie alle Einstellungen des jew. Accounts, über die Geräte gesynct werden: Einstellungen -> "ANONYMISIERTE ANALYSEDATEN" -> "Zustimmung zur Übermittlung von anonymisierten Analysedaten verweigern"
3. Synapse: "--report-stats=no" bei der Installation angeben bzw. in der homeserver.yaml:
enable_metrics: False report_stats: False
...und wie mir eben erst auffiel, ist das hier wohl auch keine schlechte Idee:
push: redact_content: True
Gruß Roland
Hi,
habe ja lange nicht mehr geschrieben, lese aber ab und an hier mit.
Die gleiche Frage haben wir uns bei Digitalcourage auch schon gestellt. (mit ähnlich langen oder sogar noch längeren Threads ;)
On 21.01.2018 11:15, Roland Hummel wrote:
Die Bewertungskategorien waren demnach:
- Freie Software für Clients und Server
- dezentraler/föderaler Betrieb möglich
- Clients für Windows/GNU-Linux/Mac/Android/iOS
- keine Bindung an Telefonnummer
- absolut verlässlicher Nachrichtentransfer
- e2e-Verschlüsselung in Einzel- und Gruppenchats möglich
Das waren in etwa auch unsere Kategorien.
Ich werde immer wärmer mit Wire.
Ansonsten sind hier unsere Ergebnisse: https://digitalcourage.de/digitale-selbstverteidigung/alternativen-zu-whatsa...
Ich hoffe, es hilft und vielleicht gibt es ja sogar Rückmeldung dazu?
lg Leena
PS: Sobald Briar aus der Beta raus kommt, gehört es auch in diese Liste. Ich warte schon ungeduldig ;)
Hi Leena,
On 04/25/2018 12:14 AM, Leena wrote:
Die Bewertungskategorien waren demnach:
- Freie Software für Clients und Server
- dezentraler/föderaler Betrieb möglich
- Clients für Windows/GNU-Linux/Mac/Android/iOS
- keine Bindung an Telefonnummer
- absolut verlässlicher Nachrichtentransfer
- e2e-Verschlüsselung in Einzel- und Gruppenchats möglich
Das waren in etwa auch unsere Kategorien.
Ich werde immer wärmer mit Wire.
Naja, aber Wire kann ja, zumindest aktuell, _nicht_ föderieren:
"Documentation on how to self host your own Wire-Server is not yet available but is planned. Federation is on our long term roadmap."
( https://github.com/wireapp/wire-server )
Auch die fehlende App via F-Droid wäre mir ein Ausschluskriterium (wurde wohl bereits 2016 angemerkt: https://github.com/wireapp/wire-android/issues/5 ).
Ansonsten sind hier unsere Ergebnisse: https://digitalcourage.de/digitale-selbstverteidigung/alternativen-zu-whatsa...
Danke für den Hinweis, allerdings aus meiner Sicht etwas inkonsequent in der Argumentation:
1. "Möglicherweise problematisch ist bei Riot der „Serverzwang“. ... Allerdings muss man nun den vielen „kleinen“ Netzknoten vertrauen, über die man kommuniziert, was nach Ansicht mancher Sicherheitsfachleute noch gefährlicher sein kann als zwar zentralistische, dafür aber professionell betriebene Serverstrukturen." -> Gilt 1.) genauso für XMPP, wird aber dort nicht aufgeführt und 2.) scheint mir das IT-Sicherheitsargument hier eigenartig gewichtet, da in diesem Satz Sicherheit stärker als Freiheit gewichtet wird.
2. "„Matrix“ (Vorsicht: Google Analytics!)" -> Könnt ihr streichen, wurde meines Wissens Ende 2017 durch Piwik ersetzt und auf den Seiten finden sich keine GA-Skripte mehr. Bei Interesse kann ich euch einen Mailwechsel mit dem Hauptentwickler weiterleiten.
Ich hoffe, es hilft und vielleicht gibt es ja sogar Rückmeldung dazu?
Insgesamt würde ich empfehlen, den schönen Artikel klarer und konsequenter anhand eurer Anforderungsmatrix zu gewichten. Signal (und eigentlich auch Silence) passen anhand dieser nämlich bei genauer Betrachtung nicht in die Liste der empfohlenen Messenger (es sei denn, man legt vorher per Punktesystem fest, was als "empfohlen" gilt, aber dann hat man eventuell auch ganz schnell propr. Systme in der Liste, weil Threema ja an sich ein super Messenger ist, aber halt proprietär).
Gruß Roland
Moin Leena,
Am Mittwoch 25 April 2018 00:14:10 schrieb Leena:
https://digitalcourage.de/digitale-selbstverteidigung/alternativen-zu-whatsa...
Danke fürs Veröffentlichen, das ist eine schwere Fragestellung und wir brauchen dafür alle Argumente und Denkkraft, welche wir bekommen können!
Ich hoffe, es hilft und vielleicht gibt es ja sogar Rückmeldung dazu?
Es ist ein guter Beitrag zur Debatte und Suche, weil die Gründe drin sind.
Ein paar Ideen und Anmerkungen von mir:
* https://swift.im/ halte ich für eine XMPP Client der Crossplattform für den Arbeitsplatz auf Mac, Gnu und Windows geeignet ist. (Ich vestehe das Geschäftsmodell, der Klient ist nach Benutzbarkeitsaspekten entworfen.)
* Als Kriterium würde ich aufnehmen: Ich kenne und verstehe das Geschäftsmodell, es ist gefunden und solide und anhand der Privatsphäre ausgerichtet.
* Das Kriterium Datenverlust halte ich so kritisch, dass ich sagen würde: es führt zu Abwertung. Ist ein Problem für XMPP, wenn nicht klar gesagt werden kann: Wenn Kriterium X eingehalten wird, ist die Übertragung von XMPP zuverlässig. (Zumindest ist mir X nicht klar, hier braucht es eine klare Aussage, denn wenn das nur mit einigen Servern und Clients geht, dann muss ganz klar sein, mit welchen.)
* Messenger sollten tauglich für Mobilnutzung sein, das ist Stromverbrauch bedeutet aber wohl auch: Welche Übertragungstechnik wir genutzt. Z.B. auf Android Google's Firebase Cloud Messenging oder geht es auch anders.
* Es muss möglich sein die App unabhängig von einem "Store" zu bekommen. Leider läßt Fdroid nur bestimmte Geschäftsmodelle zu (also freiwillig zahlen, extern von Fdroid.)
* Wie habt Ihr eigentlich keybase.io Messenger bewertet? Ist wohl Freie Software.
Die Anzahl der Kommunikationspartner ist wichtig und auch die Nutzbarkeit, die Frage ist immer: Kann ich das auch meinen Basketballkollegen empfehlen? Obwohl ich Threema proprietär ist, kommt es trotzdem weit oben raus. :/
Wir als Freie Software Gemeinschaft müssen uns fragen, wie wir für einen Anbieter ein attraktives Geschäftsmodell schaffen können, der hier auch mit Freier Software und Federation erfolgreich sein kann. Vielleicht Threema "frei" kaufen? Da fehlt noch die Federation. Hmmm...
Gruß, Bernhard
Hallo Leena.
On 25.04.2018 00:14, Leena wrote:
Ansonsten sind hier unsere Ergebnisse: https://digitalcourage.de/digitale-selbstverteidigung/alternativen-zu-whatsa...
Vielen Dank für den Link.
Ich hoffe, es hilft und vielleicht gibt es ja sogar Rückmeldung dazu?
Drei kurze Anmerkungen:
1. Zu Matrix steht im Text:
"Allerdings muss man nun den vielen „kleinen“ Netzknoten vertrauen, über die man kommuniziert, was nach Ansicht mancher Sicherheitsfachleute noch gefährlicher sein kann als zwar zentralistische, dafür aber professionell betriebene Serverstrukturen."
Im Absatz zu XMPP fehlt ein entsprechender Hinweis. Müsste das bei XMPP nicht auch gelten? (Ich persönlich bin ein großer Freund von Federation).
2. Im Absatz zu XMPP wird auf eine Anleitung zur Installation des XMPP-Servers Prosody auf einem RasPi verlinkt. Nach meiner Erfahrung müssen bei Prosody dringend einige Erweiterungen nachinstalliert werden, damit Prosody in Kombination mit Mobilgeräten gut funktioniert. In der verlinkten Anleitung fehlt ein entsprechender Hinweis. Ggf. findet sich eine bessere Anleitung.
3. Vor einiger Zeit habe ich mir die Privacy-Policy von Riot einmal angesehen. Weil ich davon eher weniger begeistert war, würde ich empfehlen, den aktuellen Stand der Privacy-Policy noch einmal zu prüfen. Falls diese zu beanstanden ist, könnte im Text ggf. ein entsprechender Hinweis eingefügt werden.
Viele Grüße
Stefan
Hallo Leena und Stefan,
auch von mir einige Anmerkungen zu Matrix/Riot, das ich regelmäßig nutze.
1. Wer die Verschlüsselung nutzt, braucht auch dem Serverbetreiber nicht zu vertrauen. Aber abgesehen davon muß man nur dem/n Netzknoten vertrauen, bei dem der/die Kommunikationspartner sitzen. Sobald alle Kommunikationspartner bei einem Knotenbetreiber sind, hat man eine quasi zentralistische Situation. Und wie Stefan schrieb, spricht dieses "Argument" gegen alle föderierten Systeme, auch gegen das empfohlene XMPP.
2. Ich kann kein google-analytics finden. matrix.org und riot.im nutzen piwik. Das kann allerdings vor mehreren Monaten noch anders gewesen sein. Die Entwickler lernen dazu.
3. Die Datenschutzerklärung von Matrix/Riot war lange Zeit völlig veraltet. Das Team hat in den letzten Monaten am Datenschutz (und nicht nur an der Erklärung) intensiv gearbeitet. Im übrigen kann man über github auch Einfluß auf die Entwicklung nehmen. Sachkundige Verbesserungsvorschläge werden gehört. Sofern im Datenschutz noch irgendetwas zu beanstanden ist, würde ich das an die Entwickler weiterleiten.
4. Matrix ist mit Hilfe von Riot deutlich einfacher zu nutzen als XMPP.
5. Es gibt dazu mit Matrix.org einen professionell betriebenen, offenen Server.
6. Viele FOSS-Projekte nutzen mittlerweile Matrix als Support-Channel, auch wegen der guten Anbindung an IRC.
7. Alle im Text aufgeführten Vorteile von XMPP gelten auch für Matrix/Riot.
8. Die Nutzung von Google Cloud Messaging ist kein Nachteil, sondern ein Vorteil für die an diesem Dienst interessierten Nutzer. Wer googlefrei kommunizieren will, muß ohnehin den Googlestore meiden und nutzt Fdroid.
Zu XMPP:
XMPP empfiehlt man nur, wenn man Nutzer zurück zu Whatsapp treiben will. Ich habe es nicht geschafft, XMPP mit Verschlüsselung einigermaßen zuverlässig zu nutzen und ich kenne auch niemanden, dem das gelungen ist. Die Einrichtung bei meinen Kommunikationspartnern war eine Krankheit und erforderte vor-Ort-Unterstützung. Wenn man allen seinen Kommunikationspartnern einen eigenen Server anbietet, mag es gehen. Die von mir vor ca. 4 Jahren genutzten öffentlichen Jabber-Server gibt es mittlerweile alle nicht mehr. Das ist dem Durchschnittsnutzer nicht zu vermitteln.
Metadaten kann keines der derzeit verbreiteten Systeme vermeiden. Briar soll insofern eine interesssante Alternative sein, habe ich aber noch nicht getestet.
Viele Grüße
Ilu
On Thu, Jul 26, 2018 at 09:28:18AM +0200, Stefan wrote:
Hallo Leena.
On 25.04.2018 00:14, Leena wrote:
Ansonsten sind hier unsere Ergebnisse: https://digitalcourage.de/digitale-selbstverteidigung/alternativen-zu-whatsa...
Vielen Dank für den Link.
Ich hoffe, es hilft und vielleicht gibt es ja sogar Rückmeldung dazu?
Drei kurze Anmerkungen:
- Zu Matrix steht im Text:
"Allerdings muss man nun den vielen „kleinen“ Netzknoten vertrauen, über die man kommuniziert, was nach Ansicht mancher Sicherheitsfachleute noch gefährlicher sein kann als zwar zentralistische, dafür aber professionell betriebene Serverstrukturen."
hm...vertrauen musst du den servern eigentlich ned, wenn du end-to end encryption aufdrehst. leider ist das ein schritt den du fuer jede neue konversation aktuv setzten musst, was unpraktisch ist.
Im Absatz zu XMPP fehlt ein entsprechender Hinweis. Müsste das bei XMPP nicht auch gelten? (Ich persönlich bin ein großer Freund von Federation).
- Im Absatz zu XMPP wird auf eine Anleitung zur Installation des
XMPP-Servers Prosody auf einem RasPi verlinkt. Nach meiner Erfahrung müssen bei Prosody dringend einige Erweiterungen nachinstalliert werden, damit Prosody in Kombination mit Mobilgeräten gut funktioniert. In der verlinkten Anleitung fehlt ein entsprechender Hinweis. Ggf. findet sich eine bessere Anleitung.
und genau hier musst du aufpassen: je nachdem was du installierst hast du dann teile der nachrichten am server liegen oder worst case schickst du die nachrichten unverschluesselt ueber gooogle und apple server (also schon transport verschlueselt, aber so das eben diese server den inhalt lesen koennen)
- Vor einiger Zeit habe ich mir die Privacy-Policy von Riot einmal
angesehen. Weil ich davon eher weniger begeistert war, würde ich empfehlen, den aktuellen Stand der Privacy-Policy noch einmal zu prüfen. Falls diese zu beanstanden ist, könnte im Text ggf. ein entsprechender Hinweis eingefügt werden.
hier scheinen die defaults auch je nach build unetschiedlich sein, allerdings gehts hier nach meinen letzten information in der praxis "nur" um anonymisierte usage statistiken um die software besser weiterzuentisckeln koennne (verlgeiche auch firefox telemetry). das is halt eines der probleme mit software: wenn sie alles mitschreibt und an die enwickler (anonymisiert hoffentlich) weiterleitet tun sie sich leichter herauszufinden wie und auf welchen geraeten das ganze verwendet wird, womit sie sich leichter tun zielgerichtet weiterzuenwickeln, mit den entsprechenden vorteilen auch fuer die user.
und ja, ich bin auch eher in der ecke von "nein, du sollst ueberhaupt nix ungefragt an irgendwen schicken"
lg albert
Hi!
Am 26.07.2018 um 14:40 schrieb Albert Dengg:
Im Absatz zu XMPP fehlt ein entsprechender Hinweis. Müsste das bei XMPP nicht auch gelten? (Ich persönlich bin ein großer Freund von Federation).
- Im Absatz zu XMPP wird auf eine Anleitung zur Installation des
XMPP-Servers Prosody auf einem RasPi verlinkt. Nach meiner Erfahrung müssen bei Prosody dringend einige Erweiterungen nachinstalliert werden, damit Prosody in Kombination mit Mobilgeräten gut funktioniert. In der verlinkten Anleitung fehlt ein entsprechender Hinweis. Ggf. findet sich eine bessere Anleitung.
und genau hier musst du aufpassen: je nachdem was du installierst hast du dann teile der nachrichten am server liegen oder worst case schickst du die nachrichten unverschluesselt ueber gooogle und apple server (also schon transport verschlueselt, aber so das eben diese server den inhalt lesen koennen)
Zum Glück werden in der Standardkonfiguration des Push Moduls keine Nachrichten an Google/Apple gesendet. Siehe https://modules.prosody.im/mod_cloud_notify.html
LG Paul
Hallo Leena und Stefan,
auch von mir einige Anmerkungen zu Matrix/Riot, das ich regelmäßig nutze.
1. Wer die Verschlüsselung nutzt, braucht auch dem Serverbetreiber nicht zu vertrauen. Aber abgesehen davon muß man nur dem/n Netzknoten vertrauen, bei dem der/die Kommunikationspartner sitzen. Sobald alle Kommunikationspartner bei einem Knotenbetreiber sind, hat man eine quasi zentralistische Situation. Und wie Stefan schrieb, spricht dieses "Argument" gegen alle föderierten Systeme, auch gegen das empfohlene XMPP.
2. Ich kann kein google-analytics finden. matrix.org und riot.im nutzen piwik. Das kann allerdings vor mehreren Monaten noch anders gewesen sein. Die Entwickler lernen dazu.
3. Die Datenschutzerklärung von Matrix/Riot war lange Zeit völlig veraltet. Das Team hat in den letzten Monaten am Datenschutz (und nicht nur an der Erklärung) intensiv gearbeitet. Im übrigen kann man über github auch Einfluß auf die Entwicklung nehmen. Sachkundige Verbesserungsvorschläge werden gehört. Sofern im Datenschutz noch irgendetwas zu beanstanden ist, würde ich das an die Entwickler weiterleiten.
4. Matrix ist mit Hilfe von Riot deutlich einfacher zu nutzen als XMPP.
5. Es gibt dazu mit Matrix.org einen professionell betriebenen, offenen Server.
6. Viele FOSS-Projekte nutzen mittlerweile Matrix als Support-Channel, auch wegen der guten Anbindung an IRC.
7. Alle im Text aufgeführten Vorteile von XMPP gelten auch für Matrix/Riot.
8. Die Nutzung von Google Cloud Messaging ist kein Nachteil, sondern ein Vorteil für die an diesem Dienst interessierten Nutzer. Wer googlefrei kommunizieren will, muß ohnehin den Googlestore meiden und nutzt Fdroid.
Zu XMPP:
XMPP empfiehlt man nur, wenn man Nutzer zurück zu Whatsapp treiben will. Ich habe es nicht geschafft, XMPP mit Verschlüsselung einigermaßen zuverlässig zu nutzen und ich kenne auch niemanden, dem das gelungen ist. Die Einrichtung bei meinen Kommunikationspartnern war eine Krankheit und erforderte vor-Ort-Unterstützung. Wenn man allen seinen Kommunikationspartnern einen eigenen Server anbietet, mag es gehen. Die von mir vor ca. 4 Jahren genutzten öffentlichen Jabber-Server gibt es mittlerweile alle nicht mehr. Das ist dem Durchschnittsnutzer nicht zu vermitteln.
Metadaten kann keines der derzeit verbreiteten Systeme vermeiden. Briar soll insofern eine interesssante Alternative sein, habe ich aber noch nicht getestet.
Viele Grüße
Ilu
Hallo!
Am 26.07.2018 um 17:01 schrieb Inken Lüdersen:
Zu XMPP:
XMPP empfiehlt man nur, wenn man Nutzer zurück zu Whatsapp treiben will. Ich habe es nicht geschafft, XMPP mit Verschlüsselung einigermaßen zuverlässig zu nutzen und ich kenne auch niemanden, dem das gelungen ist. Die Einrichtung bei meinen Kommunikationspartnern war eine Krankheit und erforderte vor-Ort-Unterstützung. Wenn man allen seinen Kommunikationspartnern einen eigenen Server anbietet, mag es gehen. Die von mir vor ca. 4 Jahren genutzten öffentlichen Jabber-Server gibt es mittlerweile alle nicht mehr. Das ist dem Durchschnittsnutzer nicht zu vermitteln.
Ganz so schlimm sind meine Erfahrungen mit XMPP nicht und ich nutze es sehr aktiv. Aber es stimmt schon, dass Matrix inzwischen recht zuverlässig läuft sehr leicht einzurichten ist. Allerdings sollte man meiner Erfahrung nach einen eigenen Server verwenden, da matrix.org häufig sehr langsam ist. Positiv finde ich die Vielzahl an bridges, mit denen man andere Messaging Systeme zu Matrix bridgen kann (zB. mit https://github.com/42wim/matterbridge).
Mfg Paul
Hi Paul,
On 07/26/2018 05:14 PM, Paul Schaub wrote:
Ganz so schlimm sind meine Erfahrungen mit XMPP nicht und ich nutze es sehr aktiv. Aber es stimmt schon, dass Matrix inzwischen recht zuverlässig läuft sehr leicht einzurichten ist. Allerdings sollte man meiner Erfahrung nach einen eigenen Server verwenden, da matrix.org häufig sehr langsam ist.
Die Performance der aktuellen Server-Implementierung "Synapse" ist in der Tat mangelhaft, was aber insofern positiv ist, dass dadurch die Zentralisierung eingedämmt wird. Zumindest mit https://matrix.org/blog/2018/07/19/synapse-0-33-0-is-here/ ist es aber wohl deutlich besser geworden (nutze meinen eigenen Server, daher habe ich die Änderung nicht live erlebt - bei meinen Userzahlen hat das Update keine fühlbaren Auswirkungen). Langfristig wird der Referenz-Server eine Neufassung in GO sein: https://github.com/matrix-org/dendrite
Gruß Roland
On Thu, Jul 26, 2018 at 05:01:08PM +0200, Inken Lüdersen wrote: ...
- Matrix ist mit Hilfe von Riot deutlich einfacher zu nutzen als XMPP.
sorry aber nein. ja, ich verwends auch (zT aus eigener entscheidung, zT weils halt bei projekten/veranstaltungen gewaehlt wurde und riot is zT schon noch arg buggy, von der serverseite gerade im bereich ferderation reden wir nicht. d.h. jetzt nich das es schlecht is oder mans ned verwenden soll, aber von fehlerfrei sind wir weit entfernt. ...
Zu XMPP:
XMPP empfiehlt man nur, wenn man Nutzer zurück zu Whatsapp treiben will. Ich habe es nicht geschafft, XMPP mit Verschlüsselung einigermaßen zuverlässig zu nutzen und ich kenne auch niemanden, dem das gelungen ist. Die Einrichtung bei meinen Kommunikationspartnern war eine Krankheit und erforderte vor-Ort-Unterstützung. Wenn man allen seinen
genau diese accounteinrichtung ist problematisch, ja. allerdings ist das zum groszteil eine kopf sperre. natuerlich ist es fuer manche leute einfacher es wie bei signal & co an die telefonnummer zu binden, aber ich halte genau das aus privacy gruenden auch fuer problemeatisch. sinnvolle privacy braucht halt mehr aufwand, das is leider so.
ich glaub aber das gerade bei xmpp halt ein paar dinge zusammenkommne: * ja manche clients sind broken * viele leute wollen einfach ned noch einen kontaktpunkt haben den sie vermitteln wollen, weil den meisten kommunikationspartnern is es ja (leider) wurscht was man aus den kommunikationsgraphen und co alles ableiten kann.
Metadaten kann keines der derzeit verbreiteten Systeme vermeiden. Briar soll insofern eine interesssante Alternative sein, habe ich aber noch nicht getestet.
aber grundsaetzlich lassen sich viele metadaten zB mit xmpp schon vermeiden, aber ich gebe zu es ist muehsam fuer jeden kommunikationspartener einen eigenen account zu verwenden und immer den hidden service fuer den xmpp server zu verwenden, aber ja grundsaetzlich is da schon viel machbar
briar steht bei mir auch noch auf der todo liste.
fuer mich ergibts sich aber auch: das eine perfekte system zu haben ist schwierig, zumal sich halt manche der anforderungen an ein system auch wiedersprechen.
lg albert
Ich habe es geschafft, meiner 80jährigen Mutter remote über Telefon (klicke hier, klicke da) riot.im beizubringen - XMPP wäre chancenlos gewesen.
Fehler bei Matrix/Riot erlebe ich nur in verschlüsselten Gruppenchats, bei denen ca. 50 Leute jeweils 3-4 verschiedene Endgeräte nutzen. Da kollidieren Sicherheit und Praktikabilität der Verschlüsselung ("device hasn't send the key for this message"). Ansonsten laufen Server und Clients seit ca. 2 Jahren störungsfrei.
On 26.07.2018 20:20, Albert Dengg wrote:
On Thu, Jul 26, 2018 at 05:01:08PM +0200, Inken Lüdersen wrote: ...
- Matrix ist mit Hilfe von Riot deutlich einfacher zu nutzen als XMPP.
sorry aber nein. ja, ich verwends auch (zT aus eigener entscheidung, zT weils halt bei projekten/veranstaltungen gewaehlt wurde und riot is zT schon noch arg buggy, von der serverseite gerade im bereich ferderation reden wir nicht. d.h. jetzt nich das es schlecht is oder mans ned verwenden soll, aber von fehlerfrei sind wir weit entfernt. ...
Zu XMPP:
XMPP empfiehlt man nur, wenn man Nutzer zurück zu Whatsapp treiben will. Ich habe es nicht geschafft, XMPP mit Verschlüsselung einigermaßen zuverlässig zu nutzen und ich kenne auch niemanden, dem das gelungen ist. Die Einrichtung bei meinen Kommunikationspartnern war eine Krankheit und erforderte vor-Ort-Unterstützung. Wenn man allen seinen
genau diese accounteinrichtung ist problematisch, ja. allerdings ist das zum groszteil eine kopf sperre. natuerlich ist es fuer manche leute einfacher es wie bei signal & co an die telefonnummer zu binden, aber ich halte genau das aus privacy gruenden auch fuer problemeatisch. sinnvolle privacy braucht halt mehr aufwand, das is leider so.
ich glaub aber das gerade bei xmpp halt ein paar dinge zusammenkommne:
- ja manche clients sind broken
- viele leute wollen einfach ned noch einen kontaktpunkt haben den sie vermitteln wollen, weil den meisten kommunikationspartnern is es ja (leider) wurscht was man aus den kommunikationsgraphen und co alles ableiten kann.
Metadaten kann keines der derzeit verbreiteten Systeme vermeiden. Briar soll insofern eine interesssante Alternative sein, habe ich aber noch nicht getestet.
aber grundsaetzlich lassen sich viele metadaten zB mit xmpp schon vermeiden, aber ich gebe zu es ist muehsam fuer jeden kommunikationspartener einen eigenen account zu verwenden und immer den hidden service fuer den xmpp server zu verwenden, aber ja grundsaetzlich is da schon viel machbar
briar steht bei mir auch noch auf der todo liste.
fuer mich ergibts sich aber auch: das eine perfekte system zu haben ist schwierig, zumal sich halt manche der anforderungen an ein system auch wiedersprechen.
lg albert
FSFE-de mailing list FSFE-de@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/fsfe-de
Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt. Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu behandeln: https://fsfe.org/about/codeofconduct
Hallo zusammen,
On 07/26/2018 08:20 PM, Albert Dengg wrote:
- Matrix ist mit Hilfe von Riot deutlich einfacher zu nutzen als XMPP.
sorry aber nein. ja, ich verwends auch (zT aus eigener entscheidung, zT weils halt bei projekten/veranstaltungen gewaehlt wurde und riot is zT schon noch arg buggy, von der serverseite gerade im bereich ferderation reden wir nicht. d.h. jetzt nich das es schlecht is oder mans ned verwenden soll, aber von fehlerfrei sind wir weit entfernt.
wenn mehr FLOSS-Software, die das Prädikat "von fehlerfrei sind wir weit entfernt" trägt, so zuverlässig funktionieren würde wie der aktuelle Stand von Matrix, wäre die freie digitale Welt eine akzeptiertere.
Sicher sind das am Ende immer sehr subjektive Entscheidungen, aber nach einem Jahr überzeugter "XMPP-Jüngerschaft" (eigener Server und sämtliche Verwandtschaft und Freundeskreis genötigt, diesen zu nutzen) habe ich bez. XMPP frustriert das Handtuch geworfen, nachdem ich anfing, Apple-Hardware zu leihen (!), um dann selbst festzustellen, dass XMPP (damals, Mitte 2017) mit ChatSecure absolut nicht zumutbar war. Matrix war dann jedenfalls im Vergleich eine "Erlösung", die ich unter https://www.kuketz-blog.de/messenger-matrix-das-xmpp-fuer-hobby-admins/ zur Diskussion gegeben habe: Der Server lief an einem Nachmittag und der Referenz-Client Riot funktioniert plattformübergreifend tadellos. Das ist ein Traum für jeden Hobby-Admin.
Von daher kann ich Ilus Einschätzung nur bestätigen: Es ist wirklich frustrierend, wenn eine Idee in der Theorie so überzeugende Idee wie XMPP in der Praxis so dermaßen scheitert. Und spätestens im Vergleich zu Slack gewinnt man mit XMPP kaum einen Blumentopf - auch "Kollaborationsfähigkeiten" sollte jedoch ein moderner Messenger abdecken und das tut Matrix mit Riot erstklassig.
Das schöne ist, dass es keinen Grund für Grabenkämpfe gibt. Soll halt jeder sein Universum nutzen, den Rest erlidgen Bridges. Dass ab und zu mal Nachrichten verloren gehen ist zu verkraften (denn genau das habe ich bei XMPP ständig erlebt, von daher ist es bez. der XMPP-Kontakte kein Nachteil, denn die, die auf XMPP bestehen, können ja offensichtlich mit Nachrichtenverlust gut leben).
Metadaten kann keines der derzeit verbreiteten Systeme vermeiden. Briar soll insofern eine interesssante Alternative sein, habe ich aber noch nicht getestet.
briar steht bei mir auch noch auf der todo liste.
Solange Briar 1. nur für Android verfügbar ist und 2. keinerlei Mediendateien verschickt und 3. nichtmal Links parst (um Medien wenigstens verlinken zu können), bleibt Briar ein Messenger für sehr besondere Einsatzszenarien, Alltag gehört jedenfalls nicht dazu. Dennoch: Spannendes Projekt, für dessen Entwicklung ich sehr dankbar bin.
Gruß Roland
Ich habe es geschafft, 80jährigen Senioren remote über Telefon (klicke hier, klicke da) riot.im beizubringen - das wäre bei XMPP chancenlos gewesen.
Fehler bei Matrix/Riot erlebe ich **nur** in verschlüsselten Gruppenchats, bei denen ca. 50 Leute jeweils 3-4 verschiedene Endgeräte nutzen. Da kollidieren Sicherheit und Praktikabilität der Verschlüsselung. Ansonsten laufen Server und Clients seit ca. 2 Jahren störungsfrei.
On 26.07.2018 22:42, Roland Hummel wrote:
Hallo zusammen,
On 07/26/2018 08:20 PM, Albert Dengg wrote:
- Matrix ist mit Hilfe von Riot deutlich einfacher zu nutzen als XMPP.
sorry aber nein. ja, ich verwends auch (zT aus eigener entscheidung, zT weils halt bei projekten/veranstaltungen gewaehlt wurde und riot is zT schon noch arg buggy, von der serverseite gerade im bereich ferderation reden wir nicht. d.h. jetzt nich das es schlecht is oder mans ned verwenden soll, aber von fehlerfrei sind wir weit entfernt.
wenn mehr FLOSS-Software, die das Prädikat "von fehlerfrei sind wir weit entfernt" trägt, so zuverlässig funktionieren würde wie der aktuelle Stand von Matrix, wäre die freie digitale Welt eine akzeptiertere.
Sicher sind das am Ende immer sehr subjektive Entscheidungen, aber nach einem Jahr überzeugter "XMPP-Jüngerschaft" (eigener Server und sämtliche Verwandtschaft und Freundeskreis genötigt, diesen zu nutzen) habe ich bez. XMPP frustriert das Handtuch geworfen, nachdem ich anfing, Apple-Hardware zu leihen (!), um dann selbst festzustellen, dass XMPP (damals, Mitte 2017) mit ChatSecure absolut nicht zumutbar war. Matrix war dann jedenfalls im Vergleich eine "Erlösung", die ich unter https://www.kuketz-blog.de/messenger-matrix-das-xmpp-fuer-hobby-admins/ zur Diskussion gegeben habe: Der Server lief an einem Nachmittag und der Referenz-Client Riot funktioniert plattformübergreifend tadellos. Das ist ein Traum für jeden Hobby-Admin.
Von daher kann ich Ilus Einschätzung nur bestätigen: Es ist wirklich frustrierend, wenn eine Idee in der Theorie so überzeugende Idee wie XMPP in der Praxis so dermaßen scheitert. Und spätestens im Vergleich zu Slack gewinnt man mit XMPP kaum einen Blumentopf - auch "Kollaborationsfähigkeiten" sollte jedoch ein moderner Messenger abdecken und das tut Matrix mit Riot erstklassig.
Das schöne ist, dass es keinen Grund für Grabenkämpfe gibt. Soll halt jeder sein Universum nutzen, den Rest erlidgen Bridges. Dass ab und zu mal Nachrichten verloren gehen ist zu verkraften (denn genau das habe ich bei XMPP ständig erlebt, von daher ist es bez. der XMPP-Kontakte kein Nachteil, denn die, die auf XMPP bestehen, können ja offensichtlich mit Nachrichtenverlust gut leben).
Metadaten kann keines der derzeit verbreiteten Systeme vermeiden. Briar soll insofern eine interesssante Alternative sein, habe ich aber noch nicht getestet.
briar steht bei mir auch noch auf der todo liste.
Solange Briar 1. nur für Android verfügbar ist und 2. keinerlei Mediendateien verschickt und 3. nichtmal Links parst (um Medien wenigstens verlinken zu können), bleibt Briar ein Messenger für sehr besondere Einsatzszenarien, Alltag gehört jedenfalls nicht dazu. Dennoch: Spannendes Projekt, für dessen Entwicklung ich sehr dankbar bin.
Gruß Roland
FSFE-de mailing list FSFE-de@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/fsfe-de
Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt. Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu behandeln: https://fsfe.org/about/codeofconduct
Ich habe grad gesehen, daß riot.im neuerdings bei einer Neu-Registrierung Google Recaptcha nutzt. Das ist natürlich ein No-go.
Allerdings ist es auch schwierig Alternativen vorzuschlagen, denn brauchbare FOSS-Systeme zur Robot-Kontrolle scheint es nicht zu geben.
https://github.com/emotionLoop/visualCaptcha scheint tot zu sein.
Hi Ilu,
On 07/29/2018 09:39 PM, Ilu wrote:
Ich habe grad gesehen, daß riot.im neuerdings bei einer Neu-Registrierung Google Recaptcha nutzt. Das ist natürlich ein No-go.
das ist nicht "neuerdings" so, sondern war meines Wissens schon immer so (und wurde hier auch in den immerwährenden Messenger-Grabenkämpfen min. einmal erwähnt ;) ).
Allerdings erwähnst Du es ja selbst:
Allerdings ist es auch schwierig Alternativen vorzuschlagen, denn brauchbare FOSS-Systeme zur Robot-Kontrolle scheint es nicht zu geben.
https://github.com/emotionLoop/visualCaptcha scheint tot zu sein.
Ein "No-go" ist es folglich nur dann, wenn man für seinen Matrix-homeserver unbedingt eine Registrierung mit GoogleCaptcha freischaltet - muss man aber nicht. Sinnvollerweise hat jeder kleine Dunstkreis seinen eigenen Homeserver und und für diesen kann man die Accounts auch mal eben händisch anlegen (register_new_matrix_user -c homeserver.yaml https://localhost:8448).
Diejenigen, die unbedingt auf matrix.org einen Account haben wollen, müssen halt damit leben. Für mich ist es jedenfalls verständlich, dass dort niemand Accounts händisch anlegen will. Genügend Homeserver-Alternativen gibt es unter: https://www.hello-matrix.net/public_servers.php
Gruß Roland
# Inken Lüdersen [2018-07-26 17:01 +0200]:
Metadaten kann keines der derzeit verbreiteten Systeme vermeiden. Briar soll insofern eine interesssante Alternative sein, habe ich aber noch nicht getestet.
Zu Briar: Ich hatte das während des jüngsten FSFE Community Meetings [^1] mit einigen anderen getestet. Es ist in der Tat ein völlig anderes Kommunikationskonzept vom ersten Schritt an. Um überhaupt einen Kontakt hinzufügen zu können, muss man sich analog treffen und gegenseitig einen QR-Code vom Bildschirm scannen. Zwar kann man sich dann gegenseitig weitere Kontakte empfehlen, aber diese haben einen geringeren Vertrauenslevel (ohne direkte Auswirkungen soweit ich sehen konnte). Die absolute Dezentralität kommt mit einigen praktischen Nachteilen:
- Alle Kontakte sind mit der App-Installation verbunden. Wird das Telefon gewechselt, müssen diese wohl wieder komplett neu hinzugefügt werden. - Zwei Geräte gleichzeitig für denselben Account sind nicht möglich, also kein Desktop-Client wie bei Signal oder Matrix. - Beide Gesprächspartner müssen gleichzeitig online sein, damit eine Nachricht übermittelt wird. Das ist insofern auch eine Herausforderung, als der Akkuverbrauch recht hoch ist.
Allerdings ist Briar auch genau deswegen sehr spannend:
- Nicht nur Chats, sondern auch Foren und Blogs sind möglich. - Kommunikation ohne Internet funktioniert tatsächlich recht zuverlässig über Bluetooth (WLAN hatten wir nicht getestet). - Klingt trivial, aber ich hatte beim Schreiben – auch wenn es nur ein Test war – ein echt gutes Gefühl. Keine Nachricht passiert einen zentralen, womöglich sogar proprietären Knoten und nichts geht Klartext über die Leitung.
Kurzum: Aufgrund der praktischen Probleme (auch Medienunterstützung wurde ja hier bereits erwähnt) ist Briar für "Normalnutzer" leider noch nicht wirklich alltäglich nutzbar. Ich empfehle aber auf jeden Fall, mal einen Blick hineinzuwerfen, am besten mindestens zu zweit, und die weitere Entwicklung abzuwarten und zu unterstützen.
Viele Grüße Max
[^1]: https://wiki.fsfe.org/Events/LSMandCommunityMeeting2018
Hallo.
Am 21.01.2018 um 09:56 schrieb Stefan:
ich habe noch eine Frage und wäre auch hier für einen Tipp dankbar: Welche freien Alternativen zu Whatsapp/Threema-Gruppen [0], die auch für Laien verwendbar sind, gibt es?
Je nach Laien-Status muss man entscheiden ob dezentral als Anforderung geeignet ist oder nicht. Man braucht halt einen Server und wenn man ihn nicht selbst betreiben kann oder jemanden gut kennt der ihn betreibt, dann ist es auch wieder egal ob das Netzwerk an sich dezentral ist oder nicht.
Dazu kommt noch die Frage nach der Art der Authentifizierung. Bei XMPP und einigen anderen Protokollen hast du halt separate Zugangsdaten, die flexibel nutzbar sind aber heutige Laien auch gerne mal vor unerwartete Herausforderungen stellt.
Um mit WhatsApp-gewöhnten Leuten zu schreiben (einzeln oder in Gruppen) empfehle ich den betreffenden Leuten gerne Signal. Die Lern- und Hemmschwelle ist dann gleich Null, weil es einfach fast identisch zu WhatsApp aussieht und funktioniert und dazu noch ist die App werbe- und kostenfrei.
Dass man jedem Kommunikationspartner seine Handynummer geben muss ist für mich eigentlich ein Problem aber es zeigt sich, dass doch einige Leute nicht gewillt sind, den Komfortwunsch zwecks privacy zurückzufahren. Und bei Leuten bei denen mir eine Kommunikation wichtig ist, lass ich die lieber Signal nutzen als dass ich WhatsApp nehmen muss.
Gruß, Bernd
Hi Bernd,
ich will keine Grundsatzdiskussion auslösen, aber da die FreieSoftware-Bewegung ja explizit _keine_ für eine bestimmte IT-Elite ist (oder sein sollte), sondern eine soziale (und damit für jeden mitdenkenden Menschen offen steht), einige Anmerkungen:
On 01/21/2018 11:31 AM, Bernd Wurst wrote:
Je nach Laien-Status muss man entscheiden ob dezentral als Anforderung geeignet ist oder nicht. Man braucht halt einen Server und wenn man ihn nicht selbst betreiben kann oder jemanden gut kennt der ihn betreibt, dann ist es auch wieder egal ob das Netzwerk an sich dezentral ist oder nicht.
In der Praxis mag das egal sein, für einen grundsätzlichen Anspruch an zivilgesellschaftlich kontrollierbare IT-Infrastrukturen aber nicht. Die Dezentralität an Email findet auch jede*r toll - sie ist nur so selbstverständlich, dass sie nicht (mehr) als etwas Besonderes gesehen wird. Ich erinnere meine Mitmenschen in der Messenger-Frage schlicht immer an die Vorzüge, die sie von Email gewöhnt sind, aber nicht auf Messenger-Systeme anwenden, dort aber eigentlich genauso selbstverständlich sein sollten (nicht, weil es in der Praxis einen Unterschied macht, sondern weil sie rein ideellen Selbstverständlichkeiten zivilgesellschaftlicher Kontrolle entspricht).
Dazu kommt noch die Frage nach der Art der Authentifizierung. Bei XMPP und einigen anderen Protokollen hast du halt separate Zugangsdaten, die flexibel nutzbar sind aber heutige Laien auch gerne mal vor unerwartete Herausforderungen stellt.
Auch hier: reine "Bildungssache". Bei Email geht auch niemand davon aus, sich mit der Telefonnummer authentifizieren zu können. Die Vorteile separater Zugangsdaten (bzw. einer Nicht-Kopplung an Telefonnummern) zeigen sich vor allem auch dann, wenn das Smartphone mal nicht verfügbar ist (genau wie bei Email).
Um mit WhatsApp-gewöhnten Leuten zu schreiben (einzeln oder in Gruppen) empfehle ich den betreffenden Leuten gerne Signal. Die Lern- und Hemmschwelle ist dann gleich Null, weil es einfach fast identisch zu WhatsApp aussieht und funktioniert und dazu noch ist die App werbe- und kostenfrei.
Solange "Moxie" aus Signal kein dezentrales Netzwerk macht, halte ich von Signal aus bildungspolitischen Gründen kaum etwas: hier wie da ist man abhängig von einem zentralisierten Dienst. Aber gut, es mag schlimmere Möglichkeiten geben, sich abhängig zu machen. Was ich sagen will: wenn man schon überzeugen muss, dann doch wenigstens so, dass im Blick auf zivilgesellschaftliche Kontrolle wirklicht etwas gewonnen wird (also: dezentrale/föderale Netze nutzen).
Gruß Roland
Hallo.
Am 21.01.2018 um 11:54 schrieb Roland Hummel:
Was ich sagen will: wenn man schon überzeugen muss, dann doch wenigstens so, dass im Blick auf zivilgesellschaftliche Kontrolle wirklicht etwas gewonnen wird (also: dezentrale/föderale Netze nutzen).
Inhaltlich hast du komplett Recht, auch mit deiner anderen Mail.
Letztlich gibt es aber immer wieder einen Kontext wenn ich einfach nur mit Leuten kommunizieren möchte, die nicht gewillt sind in dieser Richtung belehrt zu werden. Dann kann ich die Kommunikation entweder sein lassen oder in eine Richtung lenken, die immerhin Facebook da raus hält und mir freie Software ermöglicht.
Wie gesagt, in dem genannten Umfeld. Das aber im Real-Life allgegenwärtig ist.
Gruß, Bernd
Hallo,
# Bernd Wurst [2018-01-21 11:31 +0100]:
Am 21.01.2018 um 09:56 schrieb Stefan:
ich habe noch eine Frage und wäre auch hier für einen Tipp dankbar: Welche freien Alternativen zu Whatsapp/Threema-Gruppen [0], die auch für Laien verwendbar sind, gibt es?
Um mit WhatsApp-gewöhnten Leuten zu schreiben (einzeln oder in Gruppen) empfehle ich den betreffenden Leuten gerne Signal. Die Lern- und Hemmschwelle ist dann gleich Null, weil es einfach fast identisch zu WhatsApp aussieht und funktioniert und dazu noch ist die App werbe- und kostenfrei.
Ich möchte an dieser Stelle noch Wire erwähnen, welches ebenfalls softwareseitig Freie Software ist und auch auf Telefonen ohne Play Services funktioniert. Es benötigt außerdem nicht zwingend eine Telefonnummer zum Registrieren. Einige andere Punkte:
+ Server ist Freie Software [1] und soll bald auch self-hostable sein + Alle gängigen Features: Video/Audiochat; Bilder; die Dinger, die man früher Smileys nannte; noch einiges anderes - bei mir hoher Akkuverbrauch (wahrscheinlich weil ohne Play Services) - Nicht in F-Droid, weil anscheinend unfreie Abhängigkeiten [2]
Außerdem sei Hannes' bereits etwas älterer Blogpost [3] zu dem Thema erwähnt.
Viele Grüße Max
[1] https://github.com/wireapp/wire-server [2] https://github.com/wireapp/wire-android/issues/233 [3] https://hannes.hauswedell.net/post/2016/05/31/why-privacy-is-more-than-crypt...
Hallo Bernd,
Bernd Wurst bernd@bwurst.org writes:
Die Lern- und Hemmschwelle ist dann gleich Null, weil es einfach fast identisch zu WhatsApp aussieht und funktioniert und dazu noch ist die App werbe- und kostenfrei.
Gerade hier habe ich gute Erfahrungen mit Conversations gemacht. Zumindest in meinem Umfeld außerhalb der Free-Software-Community ist die Hemmschwelle einen weiteren Messenger zu installieren sehr gering. Früher als die meisten meiner Freunde hauptsächlich am Desktop-PC gearbeitet haben, wollte jeder einen Messenger, mit dem er alle Freunde erreichen kann, nicht mehrere. Auf Handys ist das aber offenbar etwas anders oder eventuell sind es die Leute schon gewohnt, dass manch einer Threema oder so einsetzt und dann macht Conversations auch kein Problem mehr. Für mich ist das immer eine Gelegenheit, dann auch F-Droid auf die Telefone zu bringen, aber viele nehmen auch die Bezahloption über Google Play und oft auch den kostenpflichtigen Account über Conversations. Das freut die Entwicker sicher auch. :-)
Happy hacking! Florian
Hallo zusammen,
Am 21.01.2018 um 09:56 schrieb Stefan:
ich habe noch eine Frage und wäre auch hier für einen Tipp dankbar: Welche freien Alternativen zu Whatsapp/Threema-Gruppen [0], die auch für Laien verwendbar sind, gibt es?
Kennt jemand Scuttlebutt und Patchwork? https://www.scuttlebutt.nz/
Scheint mir interessant und vollkommen unbekannt zu sein. Ich habe bisher nichts darüber gewusst.
Viele Grüße, Peter
