Mastodawn

#Matrix ist für mich gestorben. Ich werde meine Instanz wohl noch etwas laufen lassen, allerdings mir das ganze System zu kompliziert:
Ich war bis letzte Woche im @gnulinux Talk. Das lief auf meinem ("einfach zu installierendem") matrix-synapse auch mit meinem XMPP-Transport (Element ist mir zu behäbig, ich mags einfach nicht!) mit, ab und zu gab ich mal meinen Senf dazu, okay. Nun wurde das auf eine ominöse "Raum V12"-Version (??) geupdated - bei mir gehts nicht. Immerhin hat man seitens Gnulinux nachgeschaut, was los ist - heraus kam: geht nicht mit meinem Matrix-Synapse. Man gab mir außerdem zu verstehen, daß das Matrix-Synapse nicht so gut wäre. Ich bin nur user, aber ein user, der seit 2008 seinen eigenen #XMPP-Server am laufen hat. Gegen Matrix ist das ein Kinderspiel, muß ich feststellen - bzw. die Workarounds sind gut/besser dokumentiert.
Insgesamt ist Matrix aus meiner Sicht zu kompliziert, zu behäbig, für mich halt unpraktikabel.

@gnulinux So, ich habe erst jetzt bzw. mit diesem Problem bemerkt, daß ich noch ein matrix-synapse vom April 2025 habe - es wurde also noch unter Debian 12 installiert bzw. geupgraded. Unter Debian 12 war es im bookworm-backports-repo. Das gibt es unter Debian 13 garnicht.
Debian tut und sagt auch nix, wenn es kein (upgrade) Paket dafür hat.
Nun habe ich aber das Debian 14 (forky/testing) Paket drübergebügelt. Das ist vom Januar diesen Jahres (Version 1.146.0-3).
Wie ich da weiterverfahre, weiß ich noch nicht. Da ist matrix-synapse auch recht schnellebig. Hui!
Aber klar: Es liegt an der Stelle nicht an Matrix, sondern an Debian.

Robert Riemann 🇪🇺Mar 15

@HoSnoopy @gnulinux Warum unterstützt dein Synapse Raum Version 12 nicht? Gibt's da kein Software Update?

Nik | Klampfradler 🎸🚲Mar 15

@HoSnoopy @gnulinux Die Antwort, die du bekommen hast, ist Schwachsinn. Natürlich geht das mit Synapse. Nur updaten muss man den, wie jede andere Software, gelegentlich mal (im vorliegenden Fall innerhalb des letzten Jahres oder so).

Nicht an jeder grundlegenden Inkompetenz sind andere schuld und nicht nur, weil du persönlich etwas nicht kapierst, ist es noch nicht "ominös".

@nik @gnulinux Ich benutze Debian Stable. Ich habe Matrix-Synapse von der trixie-backports-quelle installiert. Eine neuere Version gibts da halt nicht. Was soll ich denn machen?

Nik | Klampfradler 🎸🚲Mar 15

@HoSnoopy @gnulinux

Das stimmt wohl, liegt aber an Debian. ejabberd ist da übrigens auch zwei Jahre alt, was momentan einige Probleme verursacht.

Dein Rant gegen Matrix ist ebenso unangemessen, wenn dein Server wegen deiner Linux-Distribution hoffnungslos veraltet ist.

Du könntest das apt-Repo von Upstream verwenden.

@nik @gnulinux Ich kann das nur von meiner Warte aus sagen. Deswegen sagte ich auch, daß es für mich nix ist, bzw. daß ich damit Probleme habe.
Ich benutze tatsächlich prosody als XMPP-Server, vor ~10 Jahren habe ich das von ejabberd auf prosody umgestellt bzw. migriert. Das ging erstaunlich einfach damals.
Upstream kenne ich nicht. Ich schaue es mir mal an. Danke!

@nik @gnulinux Öh ich sehe, daß matrix-synapse tatsächlich uralt ist.
Welche Alternativen gibt es denn?

Nik | Klampfradler 🎸🚲Mar 15

@HoSnoopy @gnulinux Eine neuere Version von Synapse.

Ich habe versucht, das Paket in trixie-backports zu updaten, aber wurde daran gehindert aus… Debian-Gründen.

@nik @gnulinux Ich habe kurz debian-testing als deb source eingetragen, danach matrix-synapse installiert, was danach nicht startete, weil das paket python3-typing-extensions auch mit geupdated werden mußte. Das habe ich dann auch getan.
Damit geht der Chat wieder! und bis auf matrix-synapse habe ich meine Debian 13 Pakete behalten.

Nik | Klampfradler 🎸🚲Mar 15

@HoSnoopy @gnulinux Ob das insgesamt ein gutes Vorgehen ist, lasse ich mal offen. Aber Glückwunsch.

@nik @gnulinux Ich weiß. Ich hatte auch Bauschschmerzen dabei. Aber immerhin ist es kein 3rd-Party-Paket, sondern von Debian selbst.
Ich wollte es eigentlich unter debian 13 von den deb-src von sid oder testing compilieren. Das wäre eher mein Weg gewesen, aber das ging auch nicht.
Ich hatte die Wahl zwischen einem recht alten und einem neuen, aber offiziell von Debian als "testing" laufendes synapse. Ich dachte "entweder es geht, oder halt nicht" :>
Ich bin da eben Ingenieur, kein Informatiker.

@[email protected]
Aus welchen #debian Gründen wurdest du gehindert?
@[email protected] @[email protected]

@[email protected]
Ich finde es halt auch blöd, nicht für eine Weile rückwärtskompatibel zu bleiben. Nicht jeder will wartungsintensive bleeding edge rolling releases fahren.
Im Fall von #ejabberd weiß ich gerade nicht, ob das Verhalten von #letsencrypt vor zwei Jahren schon angekündigt war.
@[email protected] @[email protected]

Nik | Klampfradler 🎸🚲Mar 17

@martin @HoSnoopy @gnulinux

Naja, also:

1. Synapse **ist** rückwärtskompatibel. Synapse hat lediglich ein optionales, neues Feature, das im vorliegenden Fall leider jemand auf einem anderen Server aktiviert hat. Im Vergleich zu XMPP: So, als würde jemand einen Chatraum von MUC auf MIX umstellen.

2. Man kann das neue Raumprotokoll auch als Security-Fix betrachten. Sowas passiert auch, und das könnte man in Debian entsprechend behandeln, wenn man wollte.

1/n

@nik @martin @gnulinux Was aber ehrlichgesagt auf einem arm64-Server nicht ganz einfach ist.
Immerhin konnte ich das .deb aus den matrix-org-quellen compilieren. Das muß ich dann halt mir jedem upgrade machen, was natürlich erheblich mehr Zeit kostet. da werde ich wohl nicht jedes update mitnehmen.
Im aktuellen Debian-stable / ARM64 gibt es gar kein matrix-synapse, auch nicht bei den backports. Warum das so ist, weiß ich nicht.

Nik | Klampfradler 🎸🚲Mar 17

@HoSnoopy @martin @gnulinux Aus Debian-Gründen.

Debian verlangt, dass die Software in einem Release mindestens zwei Jahre lang, besser fünf, gepflegt wird, idealerweise von Upstream. Das ist bei Synapse nicht der Fall, und auch so gut wie unmöglich. **Warum** Synapse kein LTS-Release hat, ist wiederum sehr komplex – deutlich komplexer als das Fingerpointing, das hier betrieben wird.

Podman oder eine (quasi jede beliebige) andere Distribution wären auch noch eine Option für dich.

@[email protected]
Ist das so? Es gibt doch vieles an SW was kein LTS hat und in debian ist. 🤔
@[email protected] @[email protected]

Nik | Klampfradler 🎸🚲Mar 17

@martin @HoSnoopy @gnulinux

Natürlich. Das hängt vom jeweiligen Maintainer ab.

Aber im Fall von Synapse haben die Maintainer eben keine Lust, es zu maintainen. Bei ejabberd hatten sie damals Lust, als es ähnlich schnelllebig war wie Synapse heute.

Holger Weiß Mar 17

@nik @HoSnoopy @martin @gnulinux Als Matrix aufkam wurde mir erklärt, dass es eine neue, inkompatible, monolithische Spec braucht, um das XMPP-Problem zu lösen, dass das Ökosystem durch optionale Extensions fragmentiert würde. Ich denke, es sollte als voller Erfolg gewertet werden, dass jetzt Debian und nicht mehr das Spec-Design an der Fragmentierung Schuld sind.

Nik | Klampfradler 🎸🚲Mar 17

@martin @HoSnoopy @gnulinux

3. Alle Räume, die das neue Protokoll nicht aktivieren, funktionieren weiter, auch mit uralten Server-Versionen aus Debian 11.

4. Es ist wirklich noch nicht lange her, dass ich alle paar MOnate meinen ejabberd updaten musste, um mit der Entwicklung und der Kompatibilität mit modernen Clients mitzuhalten. Damals wurden nur die Backports besser gepflegt und es gab weniger Geschrei darüber, wie scheiße das ist, wenn sich Software weiterentwickelt.

2/n

Nik | Klampfradler 🎸🚲Mar 17

@martin @HoSnoopy @gnulinux

Es werden bei Matrix leider völlig andere Maßstäbe angesetzt als seinerzeit bei XMPP. Vermutlich, weil es verbreiteter ist und disruptiver, wenn es kaputt geht. Komplexer oder schnelllebiger ist es nicht – ich habe mich mit beiden Protokollen intensiv beschäftigt, betreibe Deployments in verschiedenen Größen, habe aus Neugier Clients und Server geschrieben. Matrix ist nicht das Monster, als das es seitens der XMPP-Community verschrien wird.

3/n

Nik | Klampfradler 🎸🚲Mar 17

@martin @HoSnoopy @gnulinux

Das einizge wirkliche Hindernis für mich war bei **beiden** Protokollen bisher veraltete Software in Debian.

@nik @martin @gnulinux Der Hauptunterschied ist, daß bei Matrix halt alles gespeichert bleibt und sich damit die Datenbank auf dem Server aufbläht. So habe ich das zumindest verstanden. Und der Unterschied für den User besteht in den Clients: Da bietet Matrix, wahrscheinlich auch, weil es neu ist, viel weniger.
Ich habe vor ~10 Jahren von ejabberd auf prosody migiert (ging erstaunlich gut). Schaue ich auf die ejabberd-seite, finde ich recht schnell ein repo, das ich auch unter arm64 installieren kann. Prosody auch, wobei das glaube ich auch von Debian selbst geliefert wird.

Nik | Klampfradler 🎸🚲Mar 17

@HoSnoopy @martin @gnulinux Nichts davon hat mit den Aspekten dieses Threads hier zu tun. Es geht hier um die Maintenance von Server-Software, nicht um das UI von Clients oder die Größe von Datenbanken.

@nik @martin @gnulinux naja ums Handling im Allgemeinen geht es mir schon.
Ich muß mir ja als Server-Admin die Frage stellen, wieviel Festplattenspeicher ich dem Dienst X oder Y zubilligen kann.

Nik | Klampfradler 🎸🚲Mar 17

@HoSnoopy @martin @gnulinux

Dann kannst du diese Aspekte ja gerne diskutieren, aber bitte nicht mit mir an dieser Stelle in diesem Thread.

(An einer anderen Stelle in einem anderen Thread kläre ich gerne auch deine Missverständnisse darüber auf.)

Holger Weiß Mar 17

@nik @martin @HoSnoopy @gnulinux Was dieses Thema betrifft nehmen sich beide nichts: Tolle neue Features erfordern oft Updates bei allen Beteiligten. XMPP versucht sich daran, den Schaden per Service-Discovery so klein wie möglich zu halten, was in der Praxis mal besser, mal schlechter funktioniert. Matrix versucht das gar nicht erst. Auch okay. Absurd ist halt nur, dass Matrix mit dem Versprechen angetretenen war, das Problem zu lösen. Hat außerhalb der Matrix-Bubble schon damals niemand verstanden.

Holger Weiß Mar 17

@nik @martin @HoSnoopy @gnulinux Zu MIX vs. MUC: MIX ist unfertig und nicht deployed. In der Community plädiert eine Mehrheit dafür, die MIX-Idee zu begraben, gerade auch wegen des Kompatibilitätsarguments. Unabhängig davon herrscht aber ein noch größerer Konsens darüber, dass MIX nur dann eine Option wäre, wenn ein MIX-Raum auch via MUC-Protokoll genutzt werden kann.

Holger Weiß Mar 17

@martin @nik @HoSnoopy @gnulinux Das ist ja auch kein sinnvoller Vergleich. Das aktuelle ejabberd-Problem hängt mit von Google durchgedrückten CA-Policy-Änderungen zusammen, auf die die XMPP-Community notgedrungen mit einem TLS-Hack reagieren muss. Der Paket-Maintainer hat den nötigen Hack inzwischen bei Debian eingeworfen, so dass es Hoffnung gibt, dass er Teil des nächsten Point-Release von Debian stable wird (schon heute bekommen Admins das Update im Repo des Maintainers). Das ist also ein temporäres, hoffentlich bald gelöstes Problem und ein völlig anderer Fall, als inkompatible Änderungen im Protokoll selbst.

GNU/Linux.ch Mar 15

@nik
Die Antwort, die @HoSnoopy bekommen hat ist nicht Schwachsinn sondern wurde falsch verstanden:
Ich habe ihm gesagt, wenn man nicht weiss, wie man Synapse bedient, konfiguriert etc ist es kompliziert und habe gesagt, dass seine Version möglicherweise veraltet ist. Dazu habe ich noch erwähnt, dass ich, um die Updates einfacher zu halten, eine Zeitlang Synapse privat mit Yunohost laufen hatte.
Generell würde ich für wenige Personen immer eine bestehende Instanz nutzen.
/Joël

@HoSnoopy Matrix hat halt die "Zerstückelung" des XMPP Standards in XEPs als schlecht empfunden und dafür ein zueinander inkompatible "Raum-Versionen" erfunden um Features hinzuzufügen. Wenn dann Mal ein beteiligter Client oder Server das nicht kann geht gleich alles kaputt 🤷 man wollte es ja so...

@j_r Ah! Das hatte ich so nicht überrissen. Danke für die Erklärung!
Das ist auch etwas, was ich an XMPP mag: Die (Abwärts-)Kompatibelität von Clients. Auch wenn das zB bedeuten kann, daß man nicht mehr E2E-verschlüsselt (muß man dann halt wissen).
Da merkt man halt auch, daß es XMPP schon lange gibt, ich würde meine Hand nicht dafür ins Feuer werfen, daß es keinen C64-Client gibt ;-)