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
@stevenroose clearly ! no opinions there
but the rust embedded WG has adopted matrix as replacement for IRC, and other parts of the rust community are expected to, too
@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).
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 #XMPP. In such a situation, users of different services could have some features missing. But the basic features like chat would federate without a problem.
@0 @kekcoin @stevenroose
im definitely not up to date on the specifics of chat protocols, but i remember this thread where matrixdotorg themselves commented to explain some of the differences: https://twitter.com/matrixdotorg/status/1227506006264963072
anyhow, most of the rust people seem to just want a "open source discord-like experience" and matrix+riot gets close to that
That message that you mentioned (https://twitter.com/matrixdotorg/status/1227506006264963072) 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 @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
@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.
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.
@kekcoin @orionwl Well that's not really the point. Of course you don't need permission to run a bridge, that's what bridges are for :p But who is going to run it then? You your and me my own? That's a bit crazy, isn't it? Or is matrix.org going to run a single one for everyone? Also doesn't sound ideal.
@kekcoin @orionwl I don't see how your argument for bridges is an argument for Matrix. There's plenty of bridges for XMPP servers. There's nothing Matrix does special to accommodate bridges, perhaps it has more people working on bridges for it.
But the idea is that other services should have an incentive to federate. And once there are a few of them federating, users can get used to the idea that it's possible. It's currently just not something that people consider a thing.
XMPP has been a thing for a few decades now, and it has spawned closed silos built on top of it that a major thorn in the side of anyone who wants decentralised, open source communication infrastructure.
It's nice that it's the *idea* that other services should have an incentive to federate, but it's clearly not the reality.
@kekcoin @orionwl Wait are you going to say that silos using xmpp infrastructure internally means xmpp is bad? How about Linux? Most silos run on Linux as well. How about git? I bed WhatsApp's version controlled by git. I don't think your argument makes sense.
I don't think in all this regard Matrix and XMPP are all that different. They're both a federation protocol trying to make the IM landscape more open. Well, they're both failing.
I don't know about the first part. Matrix seems to gain popularity with the younger geekier userbase that's used to Slack and Discord.
On the second part, I believe XMPP as a protocol is way more inclusive and adoptable to try achieve a federation among existing services.
@stevenroose @orionwl No, I'm not saying that at all. I'm simply saying that saying that "other services should have an incentive to federate" seems to be wishful thinking when this hypothesis is tested against how it's actually been used.
I'm not saying XMPP is *bad*, I'm saying that its design has been subverted.
NB: I'm also not saying that it's irreversible, but the first step to fixing a problem is acknowledging it. Only then can you start investigating the causes and potential fixes.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!