FSFE-Matrix-Server (war: zu OT ... - jetzt wieder on topic Kommunikation in FOSS :-))

[Roland Hummel]

Hallo Florian,

On 11/5/19 7:46 AM, Florian Snow wrote:
> Das witztige ist, dass ich bei beiden Diskussionen, damals auf dem PC
> (so gegen 1998-2000 schätze ich) wie auch heute auf dem Telefon, schon
> auf XMPP gesetzt habe.  Ich denke mit besseren Clients auf Windows, Mac
> (wobei, da gab es was, war aber eventuell unfrei) und iOS hätte man da
> eine gute Chance, nochmal eine lange Zeit weitermachen zu können.

Ein Jahr im (konsequenten) Selbsttest probriert - war 'ne Katastrophe
aus genau den erwähnten Gründen: Conversations war grad noch so
akzeptabel, wenn man nur Text-Messaging benötigt, was aber WA nicht
ersetzt, weil AV-Telefonie fehlt - und ja, das wird unbedingt benötigt,
wenn die Verwandtschaft international ist (Lösungen wie Mumble sind in
der NUtzung nicht (mehr) vermittelbar, auch das ergab der konsequente
Selbstest).

> Rocketchat überzeugt mich jedenfalls nicht.  Das funktioniert so naja
> und wenn man sich die technische Seite anschaut, sieht man Pfusch (drei
> APIs, von denen keine das ganze Featureset unterstützt).
Die technische Seite würde mich erstmal weniger interessieren (weil die
User, die ich erreichen will, daran nicht interessiert sind), aber: Was
genau bedeutet denn "so naja"?

> Matrix ... Wenn man keine Bridges hat, ist die Frage, wodurch
> Matrix sich auszeichnet (das ist eine ernste Frage).

Spontan fallen mir folgende "Auszeichnungen" ein:

1. Es gibt mit Riot einen Referenz-Client, der auf allen (!) gängigen
Plattformen tadellos funktioniert. Das löst genau das Problem, was im
XMPP-Universum (leider!) über Jahre hinweg nicht gelöst wurde (einen
Client empfehlen zu können, der garantiert alle Features bereitstellt,
die das Protokoll bietet).
Das ist auch im User-Support eine unglaubliche Erleichterung, weil ich
so auch jemandem, der auf einer anderen Plattform unterwegs ist als ich,
sagen kann, wo bestimmte Einstellungen zu finden sind.

2. Mit Riot ist Matrix ein vollumfänglicher Ersatz für WA und Skype,
weil es eine funktionierende AV-Telefonie mitbringt (aus besagten
Gründen ist das spätestens dann unverzichtbar, wenn man internationale
Kontakte hat, mit denen ab und an auch telefoniert werden muss und diese
in der Regel und verständlicherweise nicht einsehen, zusätzlich zum
alternativen Chat-Messenger auch noch einen alternativen
AV-Telefonie-Client zu nutzen).

3. Saubere Chat-History über mehrere Devices: Ist sicher nichts, was
"Matrix only" ist, aber etwas, was mich bei XMPP immens genervt hat,
auch in Bezug auf beworbene XMPP-Vorteile: Es ist für User frustrierend,
wenn sie zwar den Vorteil erkannt haben, dass sie viel bequemer am PC
tippen können, wenn sie eh am Rechner sitzen, dann aber feststellen
müssen, dass ihr Gesprächsverlauf am dortigen Client nicht vollständig
vorhanden ist - das mag alles eine Konfigurationsfrage sein, aber ich
habe auf unterschiedlichsten XMPP-Servern nie erlebt, dass ein
"Multi-Device-History-Sync" sauber funktionierte.

4. Das Raum-Konzept von Matrix und die technische Lösung desselben macht
Kommunikation überaus flexibel/stabil:

4.1. Kommuniziert wird in Räumen und es ist egal, ob sich darin keine
Person, 1 Person oder viele Personen befinden. So kann ich aus einem 2er
Chat nach Bedarf einen Gruppenchat machen und umgekehrt.
Netter Nebeneffekt: Das macht das Migrieren von Accounts sehr
konfortabel: Ich lade in bestehende Räume/Konversationen meinen neuen
Account ein, der neue Account zieht sämtliche Rauminhalte auf den
entsprechenden Server, ich verlasse den Raum mit dem alten Account und
habe den Account migriert, ohne irgendjemandem mit "adde mal meine neue
ID" genervt zu haben.

4.2. Das Raum-Konzept ermöglicht technisch für Gruppenkommunikation eine
Unabhängigkeit von zentralen Instanzen: Geht der Server, auf dem ein
Raum ursprünglich erstellt wurde, offline, braucht das alle User von
anderen Servern im betroffenen Raum nicht zu interessieren, sie können
trotzdem weiter kommunizieren (Verlgeich zur Klarstellung des Gemeinten:
ein XMPP-MUC wäre dagegen komplett offline und bliebe es, bis der
ursprüngliche Server wieder online geht).
Dank Alias-Adressen, die User anderer Server für Räume anlegen können,
bleibt der Raum auch von außen via Alias adressierbar.
Durch diese Eigenschaft ist es für echte Heim-Server (die wirklich zu
Hause hinter einer dynamischen IP stehen), kein Problem, große/wichtige
Räume zu "hosten", denn sie können auch mal (öfter) offline gehen, ohne
bestehende Kommunikation einzuschränken. -> Fördert die Möglichkeit, mit
beschränkten Mitteln sinnvoll etwas zu einem föderalen
Kommunikationsverbund beizutragen

> Was Matrix als Teil der FSFE-Infrastruktur anbelangt, ist das
> schwierig.  Wir haben jetzt ein System-Hackers-Team, das zwar gewachsen
> ist, aber trotzdem gerade so alle vorhandenen Dienste abdecken kann.
> Wenn wir sowas offiziell anbieten, werden da ja gewisse Erwartungen an
> die Erreichbarkeit geweckt und es ist nicht so ganz einfach das
> umzusetzen.  Vor allem wird man ja auch nicht einfach XMPP wegfallen
> lassen wollen.  Prinzipiell machen wir aber vieles, so lange sich
> Freiwillige finden, die das verwalten, aber ich weiß nicht, ob das bei
> so einem Dienst, der das Potential hat, sehr zentral wichtig zu sein,
> sinnvoll ist und ob es überhaupt genug Personen gibt, die das auch
> langfristig betreuen wollen.

Fairerweise sollte ich den einzigen mir bisher im Langzeittest
aufgefallenen Negativaspekt von Matrix anführehn: Der "Hardware-Hunger"!
Man muss seine User erziehen, nicht jeden "Foodporn" in HD hochzuladen,
denn sonst frisst Matrix einem vom Speicherplatzverbrauch die Haare vom
Kopf. Da Raum-Inhalte wie gesagt immer über alle beteiligten Server
gesynct werden (und zwar mit "unendlicher History", kann da bei großen
Räumen immens viel zusammenkommen, wenn dort viel hochgeladen wird.

Davon abgesehen: Soweit ich verstanden habe wäre die FSFE auch nicht
abgeneigt, ein entsprechendes Hosting-Angebot einzukaufen, vielleicht
bietet https://modular.im/ ja Sonderkonditionen).

-

Wie auch immer: Man kann viel über Messenger-Alternativen reden.
Nachhaltig sind solche Gespräche aber nur, wenn deutlich wird, nach
welcher Anforderungsmatrix diese gewählt wurden (ganz oft scheint mir
das einzige Kriterium nur "ist nicht WhatsApp" zu sein, was langfristig
eher zu dürftigen Empfehlungen führt). Um mit gutem Beispiel
voranzugehen, hier meine Anforderungsmatrix:

1. zivilgesellschaftliche Kontrollmöglichkeit durch Freie Software für
Clients und Server
2. kein “walled garden”, sondern zivilgesellschaftliche Autonomie durch
föderalen Server-Betrieb
3. Clients mit graphischer Oberfläche für Android, GNU/Linux, MacOS/iOS,
Windows (bedeutet auch: Messengers muss auch ohne Smartphone nutzbar sein)
4. Android-App muss über F-Droid verfügbar sein oder sich selbst updaten
können
5. Unabhängigkeit von Mobilfunkverträgen (daher: eigenständige
Zugangsdaten (Username und Passwort) ohne Bindung dieser Zugangsdaten an
Telefonnummer, E-Mail-Adresse oder sonstige weitere Daten (bedeutet
auch: Nutzung muss ohne Abgleich des lokalen Adressbuchs sinnvoll
möglich sein)
6. verlässlicher Nachrichtentransfer und zuverlässige Fehlermeldung bei
Unzustellbarkeit von Nachrichten, Bildern und Videos
7. Möglichkeit zur Ende-zu-Ende-Verschlüsslung für Einzel- und Gruppenchats
8. Möglichkeit von Audio/Video-Telefonie
9. Nutzung auch als Gast möglich

Von diesen Punkten erfüllt Matrix mit Riot lediglich Punkt 9 nicht (bzw.
mehr mehr/aktuell nicht: https://github.com/vector-im/riot-web/issues/9264).

Gruß
Roland
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : 0xBE135DCD5A22CEFB.asc
Dateityp    : application/pgp-keys
Dateigröße  : 7640 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.fsfe.org/pipermail/fsfe-de/attachments/20191105/5cb3d932/attachment-0001.key>
-------------- 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/20191105/5cb3d932/attachment-0001.sig>