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.

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.

@[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 🎸🚲

@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.