PSA: reminder that also has a synapse/matrix server, if you're on here and interested in an 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.

@stevenroose @orionwl Interesting that you bring this up actually; interoperability/building bridges is the main selling point of Matrix as I understand it.

@kekcoin @orionwl Bridges it not the same as federating. Who is going to run the bridge? Everyone their own bridge? Some random person a big bridge that everyone will be using? I don't think it's the solution. Existing services that don't want to federate also don't want to run bridges.

@stevenroose @orionwl I'd consider it a pro of matrix that you don't need the communication silo's permission/approval/cooperation to bridge it.

@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 going to run a single one for everyone? Also doesn't sound ideal.

@stevenroose @orionwl Until XMPP has a better model (no bridges is strictly inferior than Matrix's model) I kind of see a flaw to your argument.


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

@stevenroose @orionwl Ah, I don't know much about the XMPP ecosystem, I understood from your response that bridges were generally not much of a thing in it.

And, well, if Matrix has more priority on building bridges, I would argue that it DOES do something special to accommodate them.

@stevenroose @orionwl

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.

@kekcoin @orionwl And bridges are not relevant to that. What's relevant is 2 things: which app users will more likely adopt and which protocol could most likely get existing services to federate.

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.

@kekcoin @orionwl What's preventing that from happening has nothing to do with the protocols themselves. But with users not caring about how their IM service functions and because of this IM companies having no incentive whatsoever to federate.

Users are not even aware of the fact that federated messaging could be possible.

@stevenroose @orionwl I do applaud your efforts for promoting this federation in e.g. Wire.

Maybe this is a very blasphemous suggestion, but is there any perspective on interoperability/federation between XMPP and Matrix?

@kekcoin @orionwl Totally not blasphemical. It has definitely been discussed/considered. I think the main problem is the exact difference I mentioned before. That in XMPP a group chat lives on a server, while in Matrix it lives on all servers. So it's hard for either server to "federate" with others.
But it might be of interest. If I knew Erlang or Lua, I'd definitely be interested in looking into a Matrix compatibility extension for respectively ejabberd and Prosody.

@stevenroose @orionwl Since it often happens in discussions that I respond only to the bad or flawed arguments, I want to make a point that you've been making a very convincing case for XMPP in general, and especially its design philosophy wrt. inclusivity and adaptibility.

@kekcoin @orionwl Hmm yeah I know that discussion tendency :) And you are right that if done without prior knowledge of that strategy or context it might seem that you're making annoying arguments. So thanks for the heads-up.
There should be a way to indicate that earlier. :)

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

@kekcoin @orionwl Well my argument is that both Matrix and XMPP need to rely on other services switching over. It'd be way more wishful thinking to expect the whole world to just leave their current chat service.

And I think existing silos using the XMPP protocol underneath is actually a very good thing for XMPP and potential future federation. It means that XMPP *does actually work* for those services. It just means that they principally refuse to federate.

@kekcoin @orionwl So if they would change their minds, they already know that the XMPP datamodel can easily be mapped to their own internal datamodel and supporting federation is known to be doable.

While if they were to decide to support Matrix federation, they'd have to do a lot more thinking on mapping data models. They might even have to change the existing experience of their existing users, god behold!

@stevenroose @orionwl Yes, that struck me as a potential(ly very significant) benefit to XMPP.

Sign in to participate in the conversation
unidentified instance
