XMPP oder Matrix? In welchem der beiden Netzwerke bzw. Protokolle wĂŒrdet ihr am Kuketz-Blog-Chat lieber teilnehmen?

@kuketzblog Ich denke, einige der Àlteren Protokolle, wie XMPP, könnten vom Design her unsicher sein.

@jr @kuketzblog Dies bedeutet nicht unbedingt unsicher, muss jedoch stÀndig auf den aktuellen Sicherheitsstandard aktualisiert werden.

Follow

@calculsoberic @jr @kuketzblog Sowas sollte man nicht einfach grundlos behaupten...

Ich bin da auch eher auf der "alt und erprobt" Seite und empfehle XMPP. Matrix hat seine eigenen Probleme, sowohl technisch (skalierbarkeit und Maintenance von Synapse is ein Problem, dazu scheinbar wenig auf Datensparsamkeit ausgelegt) als auch vom Management, wie es an vielen Stellen dokumentiert wurde.
Dazu ist Matrix wesentlich zentralisierter.

· · 2 · 0 · 3

@unicorn @jr @kuketzblog Ich war mir nicht sicher, aber ich bin Teil einer Sicherheitsgruppe und einige der Mitglieder hatten ihre Sicherheit in Frage gestellt. Einige Beispiele: cutt.ly/1gmVo2E - Diese wurden möglicherweise gepatcht.

@calculsoberic @unicorn @jr @kuketzblog Ja in Software von Cisco ist immer ne Menge Potential fĂŒr Verwundbarkeit...

aber was Cisco Jabber mit XMPP zu tun hat ist mir fraglich?

Nur weil da Jabber drauf steht, hat das imho sehr wenig mit Jabber/XMPP zu tun... vielleicht basiert es darauf..

@cybastl @calculsoberic @unicorn @jr @kuketzblog Cisco ist mit Jabber ziemlich weit vom heutigen XMPP entfernt. Ja, man kann sich da noch Nachrichten zwischen Cisco IM&P/Jabber und XMPP schicken, aber der Rest der XMPP Welt hat sich in den letzten Jahren massiv weiterentwickelt, zumindest was das Messaging angeht.

Cisco Jabber hat Vorteile, wenn es um CTI und Telefonie geht.

@cybastl @calculsoberic @unicorn @jr @kuketzblog Man muss ja nur mal auf ciscocollabcustomer.ideas.aha. schauen, um zu sehen, dass XEP-0363 (HTTP File Upload), XEP-0424 (Message Retraction), XEP-0308 nicht supportet ist. XEP-0045 hat so seine Probleme und XEP-0369 ist nicht implementiert und XEP-0384 (OMEMO/E2EE) ist gleich "not likely to implement" eingestuft worden.

Sachen, wo die XMPP Community schon deutlich weiter ist...

@unicorn @calculsoberic @jr @kuketzblog
Das ist doch absolut unwahr.
Sogar das Gegenteil ist wahr: wÀhrend MUCs in XMPP zentralisiert sind, sind RÀume in Matrix dezentral, in Zukunft sind sogar Accounts dezentral.

@siguile @unicorn @calculsoberic @jr @kuketzblog

Aber du weißt schon, dass es viele XMPP-Server gibt und dass die völlig unabhĂ€ngig voneinander funktionieren? Da wĂŒrde ich nicht von einem zentralisierten, sondern einem dezentralisierten System sprechen. Peer2peer ist es freilich nicht.

@chpietsch @unicorn @calculsoberic @jr @kuketzblog Was hat das damit zu tun? Das ist bei Matrix identisch. Ein Unterschied ist, dass ein XMPP Server absolute Kontrolle ĂŒber einen MUC hat, wĂ€hrend unter Matrix RĂ€ume komplett dezentral existieren.
Versucht z.B. ein Server Manipulation, können die anderen das aufdecken. Geht ein Server offline, lĂ€uft die Kommunikation auf den anderen weiter und sobald der andere wieder verbindet kommt, werden die RĂ€ume wieder zusammengefĂŒhrt, etc.

@siguile Du schriebst, dass MUCs bei XMPP zentralisiert sind. Das stimmt nicht. Bei Signal, Wire, Telegram und Whatsapp sind MUCs zentralisiert.

@chpietsch Ich habe mich doch begrĂŒndet.

Ein MUC stehen zu jeder Zeit unter der alleinigen Kontrolle eines Servers (=zentralisiert). Ist doch nicht schwer zu verstehen.

@siguile Erstens ist "freie Wahl des Servers" nicht zentralisiert und zweitens sind verteilte MUCs seit etwa 2010 standardisiert (XEP 0281,0282 und 0289) und etwa in Isode M-Link seit etwa 2012 implementiert und ist im produktiven Einsatz unter anderem bei der NATO. Hier hat einfach nur noch niemand dutzende Millionen VC reingeworfen um die ganzen verschiedenen open-source XMPP Server (dezentrale codebase und Entwicklung ist ĂŒbrigens auch ein wichtiger Dezentralisierungs-Aspekt) anzupassen.

@larma wo habe ich denn behauptet, dass die freie Wahl des Servers zentralisiert ist?

@siguile Naja du sagtest MUCs wĂ€ren zentralisiert und das ist einfach falsch da man den Server des MUCs frei wĂ€hlen kann oder eben auch wĂ€hlen kann dass ein MUC auf mehreren Servern ist. Nur weil das in der Praxis selten gemacht wird weil es hĂ€ufig mehr Nachteile als Vorteile mit sich bringt, heißt das nicht, dass XMPP das nicht beherrscht. Matrix hat sich halt dazu entschieden, die Nachteile fĂŒr alle in Kauf zu nehmen, bei XMPP ist das optional.

@larma der MUC ist trotzdem zentralisiert, egal auf welchen Server er ist

@siguile Entweder hast du meine Nachricht nicht richtig gelesen, oder dein "Zentralisierungs"-Begriff wĂŒrde dann genauso auf Matrix-RĂ€ume zutreffen.

Man kann MUCs so mit mehreren Servern benutzen, dass jede Nachricht an jeden Nutzer im Raum geht, es sei denn der Server des empfangenen Nutzers zensiert. Das ist bei Matrix genauso. Es verzichten bei XMPP nur ungefĂ€hr alle Clients/Server aus Performance-GrĂŒnden darauf.

@larma Bitte lies dich mal ein wie RĂ€ume in Matrix funktionieren. Ich hoffe der dezentrale Charakter jener wird dann klarer.
Ich könnte das zwar nun erklÀren, aber wozu, wenn es viel detaillierter in den weiten des Internets erklÀrt wird

@siguile Mir ist bewusst wie Matrix funktioniert, ich denke nur, dir ist nicht bewusst dass und/oder wie verteilte RĂ€ume in XMPP in der Praxis funktionieren, wenn sie jemand nutzen wollen wĂŒrde.

Das Hauptproblem dabei ist aber die Konsistenz - und dieses Problem hat auch Matrix ĂŒberhaupt nicht im Griff - wenn die Server-Last hoch ist kommt es da problemlos zu dutzenden verschieden-geordneten Chat-VerlĂ€ufen, je nachdem was dein Server so zuerst verarbeitet hat.

@larma Was könnte denn Matrix deiner Meinung nach an dem Algorithmus (matrix.org/docs/spec/rooms/v2) verbessern?
PS: Mit der Zeit (eventually -> eventual consistency) sollte eine Konsistenz hergestellt werden

@siguile Das Problem ist nicht der Algorithmus, das Problem ist, dass das Protokoll so designed ist, dass man diesen Algorithmus braucht.

Je mehr Teilnehmer in einem Netzwerk Ihre eigene Meinung ĂŒber den Zustand eines Dokuments haben, desto schlechter lĂ€sst sich das System verteilen. Das ist der Grund warum NoSQL und Object Storage inzwischen so populĂ€r sind: Sie skalieren sehr gut horizontal, da es fĂŒr jedes Dokument nur einen Teilnehmer gibt, der autoritĂ€r den Zustand definiert.

@larma das Ziel ist ja gerade, dass eben nicht ein Teilnehmer die komplette AutoritÀt hat, sondern jene dezentral verteilt ist. Aus selbigen Grund wird ein solcher Algorithmus benötigt.
Und ich finde das auch gut so.
Und freue mich auch schon darauf bis das selbe bei den Accounts (optional) der Fall ist

@siguile Ich wollte lediglich das eine und das andere extrem aufzeigen. In einem effizienten System gilt es einen guten Mittelweg zu finden.

Ist es wirklich notwendig den Chat-Raum mit 20 Leuten auf 20 Servern zu fĂŒhren oder wĂŒrden vielleicht 3 auch völlig ausreichen um deinen Dezentralisierungsanforderungen gerecht zu werden? Was genau ist dein Ziel bei der Dezentralisierung außer den Ressourcenverbrauch zu erhöhen? Das sollte man nie aus dem Blick verlieren.

@siguile Solange jeder matrix.org benutzt ist alles gut, aber sobald andere Server ins Spiel kommen wird Matrix stellenweise wirklich unbrauchbar. Ich rede hier von Latenzen im Bereich von Stunden, Nachrichten die nur bei manchen Nutzern auftauchen usw. Das sollte fĂŒr ein Chat-System untragbar sein, bei Matrix-Fan-Boys heißt es aber nur, dass man einen leistungsstĂ€rkeren Server braucht und weniger Nutzer auf matrix.org (obwohl letzteres eigentlich Ursache des Problems ist).

@larma das ist so nicht korrekt.
Solche Latenzen waren(!) im Allgemeinen (klar, kannst du es auch auf einem eigenen Server durch langsame Verarbeitung provozieren) auch nur im Zusammenhang mit matrix.org zu sehen.
Status quo lÀuft ein Raum mit 1000+ Servern ohne merkbare Verzögerungen.
Mittelfristig gibts auch noch einiges an Optimierungspotential, z.B. könnte man von full mesh weggehen (im Zusammenhang mit p2p beabsichtigt) oder auf effizientere Server wechseln

@siguile Ich habe vor ein Paar Wochen noch genau diese Problem gehabt. matrix.org war auch beteiligt, aber die Problem traten auch bei Nutzern anderer Server auf.

Auf welchem Server gibt es denn in der Praxis keine solchen Probleme, wenn man ein Paar großen RĂ€umen beitritt?

@larma aktuell weder bei nitro.chat, noch privacytools.io, und wenn es auftritt, nur mit dem Server, der Probleme macht.
Macht matrix.org Probleme, sind halt die Nutzer betroffen, die auf dem Server sind, und die, die ĂŒber die Bridges dieses Servers angebunden sind.

@larma @siguile dem muss ich ganz klar wiedersprechen, ich benutze Matrix fĂŒr ~30% meiner Kontakte, alle auf anderen Servern (_nicht_ matrix.org und _nicht_ mein homeserver) und das funktioniert ziemlich gut.
Dass die einzige brauchbare homeserver implementation kein bisschen resourcensparend oder performant ist, ist aber wahr.

@pbb @siguile Ich will gar nicht ausschließen, dass es gute Erfahrungen gibt, aber ich habe mehrmals absurd schlechte Erfahrungen gemacht. Und eben nicht vor langer Zeit sondern vor ein Paar Wochen.

Ich hatte da in einem Chat geschrieben und meine Nachrichten kamen bei den meisten anderen auch innerhalb von einer Minute an, Nachrichten von anderen kamen aber zwischen ein Paar Minuten und Stunden spĂ€ter an - je nach Server. Entsprechend inkonsistent die Chat-VerlĂ€ufe. FĂŒr mich ist das untragbar.

@larma @pbb riecht nach dem Maleur bei der ausgehenden Föderation von matrix.org 😀

@siguile Wieso nur matrix.org, im Raum waren auch genug Leute nicht von matrix.org aber gefĂŒhlt gigantische Latenzen (alles ĂŒber ein Paar Sekunden ist fĂŒr "Instant" messaging gigantisch) gab es eigentlich immer. Wahrscheinlich war auch der von mir genutzte Server etwas ĂŒberlastet (librem.one) - aber wenn regelmĂ€ĂŸig angeblich die Server ĂŒberlastet sind lĂ€uft doch irgendwas grundsĂ€tzlich falsch.
Vielleicht lÀuft Matrix ganz ok, wenn jeder Server nur 10 Leute hat, aber das ist nicht paxistauglich.

@larma Matrix.org hat 7 mio registrierte accs und lÀuft damit recht fix.
dass synapse allerdings ĂŒbermĂ€ĂŸig ressourcen braucht, ist allseits bekannt.

@larma PPS: ich wollte mit dem aktuellen Standard von MUCs im XMPP Ökosystem vergleichen

@siguile Du kannst heute hingehen und einen MUC mit deinen Freunden auf Server A und einen auf Server B machen. Und dann schickt ihr einfach jede Nachricht immer an beide MUCs. So kann weder Server A noch Server B Nachrichten zensieren oder durch einen Ausfall die Kommunikation blockieren (was wohl die wichtigsten GrĂŒnde fĂŒr dezentral sein dĂŒrften). Die beiden MUCs sind zwar nicht eventually consistent, aber das ist ja auch nicht notwendig, solange es die Clients sind.

@larma d.h. ich erstelle bei 10.000 Leuten aus 1000 verschiedenen Servern 1000 MUCs, welche dann mit der Zeit immer weiter voneinander abweichen, und ich dannn 1000 verschiedene Historien habe? what?

@siguile Wieso brauchst du 1000 Server, vermutest du, dass die anderen Server sich byzantinisch (keine Ahnung ob man das auf deutsch so sagt) verhalten? Du musst doch nur dafĂŒr sorgen, dass du jede Nachricht von mindestens einem Server bekommst.

@larma wenn man nur auf die Nachrichtankunft abzielt: ja

Mir wĂŒrde das aber nicht reichen, und wĂŒrde auch gerne sĂ€mtliche Nachrichten auf meinem Server haben.

Es gibt viele Vorteile abseits "dafĂŒr sorgen, dass jeder die Nachrichten bekommt". DarĂŒber, ob auch die Option da sein sollte einen Distributionsserver (bzw. ein subset von besitzenden Server) zu haben, kann man gerne diskutieren. Gibt dazu auch auf dem repo Diskussionen.
Aktuell wĂŒrde ich aber den Bedarf nicht sehen...

@siguile Es ist ja in Ordnung, wenn dein Server eine Kopie der Nachrichten vorhĂ€lt als Archiv fĂŒr die eigenen Nutzern. Aber dafĂŒr braucht er ja nicht gleich mitreden dĂŒrfen, was die richtige Historie ist. Das ist m.M.n ein schlechtes Design, da es unnötig Last im System verursacht.

@larma deine Meinung habe ich zur Kenntnis genommen.

@siguile Mir scheint du versuchst die Fehler von Matrix nach XMPP zu ĂŒbertragen. Das funktioniert natĂŒrlich nicht unbedingt so gut, kann aber wohl kaum als notwendig erachtet werden.

@siguile
Hör doch mal auf rumzuquĂ€ngeln, dein Argument wurde inkl. Quellenangaben wiederlegt. Kies dir die XEPs doch mal durch. Nebenbei fĂŒhle dich nicht von Matrix angebracht und verbessere es gerne weiter.
@larma

@vv01f @larma Welches Argument soll deiner Meinung nach wiederlegt sein?
Ich quÀngel nicht rum, sondern habe lediglich eine Falschaussage korrigiert.

@larma "WARNING: This document has been automatically Deferred after 12 months of inactivity in its previous Experimental state. Implementation of the protocol described herein is not recommended for production systems. However, exploratory implementations are encouraged to resume the standards process."
Standardisiert bei XMPP ist auch so ne Sache: Auf dem Papier mag das sein, aber im existierenden Ökosystem schaut es dann wieder ganz anders aus.

@siguile
Naja, die gesamte Matrix spec ist ungefĂ€hr in dem Zustand, wo man bei der XSF sagen wĂŒrde "not recommended for production systems" - das ist nĂ€mlich immer dann der Fall, wenn noch Änderungen an der spec zu erwarten sind. Das ist also mehr Terminologie.

Und wie gesagt, M-Link hat das seit gefĂŒhlten Ewigkeiten implementiert. Klar hat das nicht jeder Server, aber ich sag ja auch nicht Matrix kann etwas nicht weil es einen Client oder Server gibt der es nicht kann.

@larma Bei Matrix werden immer Änderungen an der Spec zu erwarten sein. Das ist essentiell um mit der Zeit mitgehen zu können.
XEP-0289 ist noch nicht einmal fertig ausformuliert und hat ne Todo section. 0281 verweist auf selbige.

@siguile @chpietsch @calculsoberic @jr @kuketzblog Das ist ein guter und valider Hinweis :)

Ich meinte das nicht auf die Technologie bezogen, sondern auf die Verteilung der Nutzer auf die verschiedenen Instanzen. Momentan sind Nutzer ja auch bei Matrix instanzgebunden, und die große Mehrheit ist auf matrix.org.

Meine persönlichen Probleme mit Matrix sind eher die anderen.

@unicorn @chpietsch @calculsoberic @jr @kuketzblog
"Momentan sind Nutzer ja auch bei Matrix instanzgebunden, und die große Mehrheit ist auf matrix.org. "
Ein Drittel von denen, ĂŒber welche matrix.org Bescheid weiß

@siguile Dann hat es sich wesentlich verbessert seit meinem letzten Stand, ich nehme den Punkt zurĂŒck :)

@siguile
Dezentrale RĂ€ume sind aber schlecht fĂŒr PrivatssphĂ€re. WĂ€hrend bei XMPP eine Nachricht die ich sende bei jedem Client ankommt und dann von den Servern verschwindet, bleibt sie bei Matrix auf jedem Server der sie empfangen hat liegen.
Und im Gegensatz zu den meisten Client-Rechnern sind Server ja stĂ€ndig erreichbar fĂŒr Angreifer.
Der Komfort "Ich habe meine Chatlogs in der Cloud" von Matrix ist fĂŒr PrivatssphĂ€re eher bedenklich.

@kuketzblog

@siguile
Das hat mit meinem Punkt nichts zu tun. Es sei denn in deinem persönlichem Chatlog sollen auch keine Namen mehr stehen.

Wenn du so willst hat Matrix auf jedem Server der am Raum beteiligt ist ein Chatlog in der Cloud gespeichert.
XMPP hat fĂŒr jeden Client der beteiligt ist ein Chatlog auf dem Clientrechner gespeichert.

(Wobei einige XMPP-Clients auch nicht loggen, bzw. man das Logging deaktivieren kann. Aber du musst damit rechnen dass Leute ein Log haben)

@kuketzblog

@allo @kuketzblog
Doch hat es. Wenn nicht, darfst du gerne erlÀutern, wo du noch ein Problem siehst.
XMPP bietet auch die Möglichkeit chatlogs auf dem Server zu speichern.
Sogar auf fremden Servern, laut Standard, Xep 0313 Abschnitt 6.1.1

@siguile
Ich halte Mastodon mit 500 Zeichen nicht fĂŒr das geeignete Medium fĂŒr lĂ€ngere ErklĂ€rungen. Aber ich empfehle einfach mal genau nachzulesen wie die beiden Protokolle jeweils funktionieren von der Nachricht bei mir bis zu der Nachricht bei dir.
Ansonsten klinke ich mich an dieser Stelle aus der Diskussion wieder aus, ich sehe zu sehr einen XMPP vs. Matrix Flamewar der keinen weiterbringt.

@kuketzblog

@allo @kuketzblog
Keine Sorge, ich habe nachgelesen wie die Protokolle funktionieren.

@js @siguile
Jain. MAM ist eine pro-user Sache und hÀlt per Default 2 Wochen vor. Matrix funktioniert im Prinzip dadurch, dass die Server alle ihr Archiv miteinander synchronisieren und dauerhaft speichern.
Das Problem dass ich nicht weiß was andere mit Logs machen habe ich natĂŒrlich immer, aber ein System das darauf ausgelegt ist Nachrichten zuzustellen statt vorzuhalten ist mir irgendwie lieber.

@kuketzblog

@js @siguile
Ich habe ĂŒbrigens mal probiert MAM mit lĂ€ngeren Archivzeiten zu nutzen, weil ich wollte dass auch Clients die selten online sind noch alles sehen können.

Das funktioniert aber nicht vernĂŒnftig, denn z.B. gajim hĂ€ngt dann beim Start erst einmal einige Minuten wĂ€hrend es die Logs aus MAM synchronisiert.
Das ist wirklich nicht als Log-Archiv gedacht, sondern nur ein kurzer Cache um abzufedern wenn ein GerÀt ein paar Tage nicht online ist.

@kuketzblog

@allo @siguile @kuketzblog Also ich hatte es bei mir fĂŒr immer an und keine Probleme ;).

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!