PSA: reminder that x0f.org also has a synapse/matrix server, if you're on here and interested in an :x0f.org address let me know

@orionwl XMPP is clearly the superior federated IM protocol! 😂

@kekcoin @orionwl Meh, basically way more mature server implementations. Synapse is a piece of garbage if you compare it with f.e. ejabberd.

@stevenroose @orionwl Nitpick: so it's not the *protocol* that's superior? Any opinion on that? I do like the principles behind Matrix but no idea if those are present in XMPP as well (just without a modern video introducing the concepts).

@kekcoin @orionwl Well XMPP's protocol has been proven to be quite resilient to changing user expectations. It's incredible extensible (as the name suggests) so basically anything can be added on top. I'm convinced all IM applications people use nowadays can be implemented using XMPP and could federate the features they have in common.
For as much as I've read into it, Matrix seems much more focused on getting it's current use-case right without leaving all that much room for the future.

@kekcoin @orionwl I guess that's kind of a product of our current time, as compared with how protocols were generally designed in the past.
That being said, I think Matrix has one feature that would be hard to implement in XMPP in a backwards-compatible way and that is group chats that don't have a single hosted server. Current XMPP group chats (MUC) and the next generation of group chats (MIX) both have a single "owning" server per group chat.

@kekcoin @orionwl So while of course it's possible to implement Matrix-style group chats in XMPP. (I believe there's actually 2 extension specifications that do exactly that), they are not backwards compatible so clients and servers will have to implement them and users with clients and servers that don't implement them won't be able to use them.

@kekcoin @orionwl However I think for a communications system, a federated status quo would already be an incredible improvement over the current status quo. I don't see a need to go beyond that, as XMPP has been proven to work in situations where there's a very low number of users per server (i.e. a world where many people self-host in small groups).

@kekcoin @orionwl
So to come to my point. I don't think we want everyone to go and start using "new chat app named X". We should want people's existing favorite chat app to federate with each other.
There is currently nothing except selfish interest that prevents WhatsApp, Hangouts, Signal, Telegram, Wire, ... to federate over . In such a situation, users of different services could have some features missing. But the basic features like chat would federate without a problem.

@kekcoin @orionwl
An interesting thread on this topic is Wire's issue on their decision for a inter-Wire federation protocol:
github.com/wireapp/wire-server

@stevenroose @orionwl

> the biggest argument would be that [XMPP]'s 20 years old and still around and being used.

Had not considered the lindy effect wrt. chat protocols before. Interesting thought.

@kekcoin

And more to the point: still being used after 20 years by the same user. Namely, truly yours. 🙂

@stevenroose @orionwl

Follow

@0 @kekcoin @stevenroose
im definitely not up to date on the specifics of chat protocols, but i remember this :birdsite: thread where matrixdotorg themselves commented to explain some of the differences: twitter.com/matrixdotorg/statu

anyhow, most of the rust people seem to just want a "open source discord-like experience" and matrix+riot gets close to that

· · Web · 3 · 0 · 1
@orionwl @0 @kekcoin @stevenroose sucks that their reference homeserver is written in Python (https://github.com/matrix-org/synapse) and has some serious issues with performance. At least they are rewriting it in Go (https://github.com/matrix-org/dendrite) now which should be better and of course there is a Rust (https://github.com/ruma/ruma) one being written too.

@orionwl
That message that you mentioned (twitter.com/matrixdotorg/statu) matches my recollection of the #matrix design principles from back when I looked at it in the early days of matrix.

Which leads me to think whether the protocol is not being abused as a chat application.

@kekcoin @stevenroose

@kekcoin @0 @orionwl He means abused in the sense that it's way more powerful than it has to be for chat purposes. Like abusing a blockchain to do chat. Or a blockchain to do pretty much anything that's not digital cash :D

For chat you need to make sure your message reaches your contact. Pretty much that. If your protocol is about syncing conversations across a network of devices, you're more like some kind of Git + Torrent + Rsync :D

@stevenroose @kekcoin @0 the nice thing about the syncing *for chat* is that the user can browse back in history, this is especially useful for public rooms (a common complaint against IRC that it needs special precautions), but also for private conversations if you're not connected 24/7

@orionwl @kekcoin @0 Sure history can be important, but for several use cases one does explicitly not want history. So if your protocol is entirely built around the idea of syncing histories, how does one accommodate those scenarios? XMPP has MAM (a protocol for history storage) and it has a protocol for temporary history storage for messages received while offline.

So privacy-aware apps that explicitly don't want history can chose to not use MAM, while it seems they wouldn't work with Matrix.

@stevenroose @kekcoin @0 agree, an option to disable history seems to not exist yet for matrix github.com/vector-im/riot-web/

OTOH in both protocols the server could secretly keep a log, despite user preferences. Only E2E encryption with perfect forward secrecy (which both XMPP and Matrix have in some form) mitigates this.

@orionwl @kekcoin @0 True. And still most (all?) E2EE implementation leave a lot of metadata as well. Some of that is even not possible to remove.
So for that reason, one will always have to somehow trust their server to do certain things for you. Like not keeping secret logs :)
Hosting your own server also help for that. And if you host your own server, keeping no history still makes sense because the server can be confiscated or hacked.

@orionwl

> Only E2E encryption

Here we go again.

What threat are you trying to mitigate exactly with end to end encryption? Forensically, the focus is on the metadata. The contents of your communications are not necessarily important nor even desirable (for a start, it complicates procedural matters and could provide a good opportunity for defence in certain cases).

> perfect forward secrecy

Leaks like a strainer in the implementations I'm aware of.

@stevenroose @kekcoin

@0 @orionwl @stevenroose Opsec matters vs. other adversaries than just ones motivated by legal frameworks.

@kekcoin

Hence the question. What is your threat exactly? You start from there and work your way towards a (comprehensive) solution. Else, we're in tinfoil hat territory.

@orionwl @stevenroose

@0 @orionwl @stevenroose I'm sorry but I find "what's your exact reason for wanting to keep things private" a rather personal question, and I don't know you.

@kekcoin

Don't be an arse. Besides, you're way out of your depth here. Ciao.

@orionwl @stevenroose

@0 @orionwl @stevenroose Not sure what part of what I said made you feel like I was being an arse, but to put my discomfort in a different way;

Publicly disclosing the specifics of my personal threat model is not in line with my opsec policy.

@0 @kekcoin @orionwl One big reason to keep things private and to reduce lingering history is that the political environment of your country can change. You have no idea what will happen to your country in the next 30 years. If right now you talk about agreeing with your current political climate, that might bring you into trouble in the future.

We know how incredibly sophisticated the illegal data collection programs of governments are. You must assume your conversations are being recorded.

@orionwl @0 @kekcoin Isn't "message passing" the exact right type of protocol for chat? Having permanent histories of everything (which seems to imply) doesn't feel like the right thing for chat.

Sign in to participate in the conversation
unidentified instance

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