Freie Alternative zu einer Whatsapp/Threema-Gruppe

Roland Hummel roland.hummel at student.hu-berlin.de
Do Jan 25 10:43:04 UTC 2018


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

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20180125/c0799a5b/attachment.sig>


Mehr Informationen über die Mailingliste FSFE-de