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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ FSFE-de mailing list FSFE-de@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/fsfe-de