Diese Woche wurde mir eine interessante Problematik in einem PoC berichtet. Es ging um die Einführung des #BundesMessenger aka #Matrix-Client.
Das Produkt ist FOSS und wurde auch für den hashtag#DStack diskutiert. Bisher war ich daher auch ein Befürworter, hatte mich aber gewundert, dass die Verbreitung bisher so gering zu sein scheint.
Jetzt weiß ich auch warum, denn offenbar ist eine Schwäche des Protokolls, dass immer eine Client-Instanz aktiv sein muss, weil andernfalls Nachrichten nicht entschlüsselt werden können. Ein Sicherheitsfeature, das für echte Real-Time-Kommunikation sinnvoll erscheint.
Nun sind wir aber im Verwaltungskontext in einer Welt, wo Menschen in der Regel von 7 bis 15 Uhr arbeiten, am Wochenende frei haben und nicht alle ein Smartphone für den Dienst gestellt bekommen und selbst dieses vielleicht nach Feierabend ausschalten. - Wir wollen ja auch alle GreenIT praktizieren und nur für eine aktive Session den Rechner laufen lassen, erscheint nicht zielführend.
Daher sehe ich hier ein komplettes No-Go zum Einsatz in der Verwaltung für das einstige Prestige-Projekt. Und da es ein Protokoll-Problem ist, scheint der Fix mit "dehydrated devices" komplex und noch nicht überall für den BM verfügbar zu sein.
https://joinmatrix.org/guide/fix-decryption-error/
Fix decryption error

A simple checklist on what to do when your Matrix client cannot decrypt messages.

Join Matrix!

@kai_brb

Ich kenne mich mit dem Matrix-Client-Server Protokoll nicht genügend aus, um das wirklich (qualifiziert) beurteilen zu können, aber so als Idee:

Macht es, wenn die "Spezifikationen" so sind, nicht evtl. Sinn permanent einen solchen Client als "Quasi-Dienst" auf einem (elektrisch sparsamen - zur Not RasPi) Server laufen zu lassen, Client die notwendigen Tasks laufend zu halten?

@EventOrg ja, das ist nach meinem Verständnis die Idee hinter dem "dehydrated client". Ein virtueller Client der die session in Abwesenheit übernimmt.
Aber das würde im Kontext Verwaltung bedeuten, dass ich für alle Angestellten (und das können in Berlin oder Brandenburg schon mehrere zehntausende sein) solche Clients brauche. Dafür brauche ich auch keine Raspi, das geht sicher mit Containern aber ist das sinnvoll?
@EventOrg ... und ist das dann noch echtes "ende-zu-ende", wenn ich den "agent in the middle" gleich mit ausrolle?
Aus der Sicht erscheint mir Matrix für M2M denkbar aber als asynchroner Messenger und Ersatz für z.B. Teams oder Slack unbrauchbar.
matrix_sdk_crypto::dehydrated_devices - Rust

Submodule for device dehydration support.

@kai_brb Das ist nicht ganz korrekt. Aktiv muss ein Client nicht sein. Er darf halt nur nicht ausgeloggt werden, weil dann Schlüsselmaterial verloren geht. Dagegen hilft das dehydrated device und das wird z.B. auch schon bei der gematik großflächig im TI-Messenger eingesetzt. U. A. bei allen gesetzlichen Krankenkassen in der ePA App.
@benkuly Danke für den Hinweis, aber soweit ich gesehen habe ist "dehydrated device" bisher nicht Bestandteil der Implementierung des @bundesmessenger und die Nutzung über Browser mit regelmäßigm Löschen des Caches erscheint mir daher schwierig.
@kai_brb @bundesmessenger Ist vermutlich nur eine Frage der Zeit. Oder halt einen alternativen Client nutzen (bspw. den extrem anpassbaren Tammy, der in einer Variante auch TI-Messenger ist). Habe eh nie verstanden, warum sich das BWI plötzlich in die Verwaltung "einmischt". Den Ansatz der FITKO halte ich für nachhaltiger.
@benkuly
Ist mit Ansatz der FITKO dieses Vorhaben gemeint?
https://gitlab.opencode.de/fitko/matrix-g2x/gitlab-profile
In dem beschriebenen Pilotvorhaben ging es um die verwaltungsinterne Nutzung, alternativ zu Slack oder Teams und idealerweise ohne extra Client sondern Browser basiert. Daher fiel die Wahl auf sen Bundesmessenger in der Version auf #opencode
Föderale IT-Kooperation (FITKO) / Matrix-based G2X communication („Neo“) / Infos zum Vorhaben Neo - Pilotierung Matrix-basierter Kommunikationskanal für die G2C-Kommunikation · GitLab

Informationen zum Vorhaben "Pilotierung Matrix-basierter Kommunikationskanal für die G2C-Kommunikation" (Neo) des Föderalen IT-Architekturboards

GitLab