> IIUC Jabber never really had decentralized group chats?
Jaber had something like that 5 years before Matrix: https://xmpp.org/extensions/xep-0289.html but decided it wasn't an avenue worth pursuing, as a non-issue in practice. This is further proven by WhatsApp (which is based on XMPP/ejabberd) and its billion active users: you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure (the erlang VM in this case).
> Matrix rooms are fully decentralized and can survive any servers failing.
In practice the room survives in a "split brain" mode where different users see different participants, the room isn't available to the users whose instance went dark as its no longer hosting their identity, and messages are popping mid history while the state resolution is working hard to reach consensus. When the servers finally come back online, there is a risk of never catching up fully, or worse, for the rooms to remain split forever.
And I adventure a hot take there: this property of staying seemingly online (in a frankenbizarre way) came handy way fewer times in the history of Matrix than for all the incurred complexity reflected in daily bugs, privacy, security, performance issues and inconsistencies.
To add some colour - there are commercial implementations of that (e.g. https://www.isode.com/whitepapers/federated-muc.html ). But from my perspective as a server developer, I've seen minimal interest in this for the public network. Probably because server failures are rare enough events in the general case.
That's not to say there aren't use cases where it is more valuable to have this functionality.
> you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure
But I don't want to trust my community to someone providing me infrastructure. Lots of projects, communities or whatever start small on third-party hosting. Many open source projects right now have rooms on gitter.im or matrix.org. I don't think they made a "bad" choice and I don't think they should need to scramble to find new rooms if their provider goes offline.
> In practice the room survives in a "split brain" mode where different users see different participants
Even if this is true (I haven't see it when servers go offline) this sounds like a bug that can be improved over time. Not a reason to give up.
But also do you have any evidence of this? Matrix rooms don't have a "home server" so if this was a bug that occurred it would occur for any member of a chat going temporarily offline, and for large chats that happens often. So it seems like if this is an issue it only happens in very niche circumstances.
> isn't available to the users whose instance went dark as its no longer hosting their identity
This is true, as I said users are federated and suffer if their homeserver goes down. But it is a huge difference to be able to set up a second account on a second server and continue participating rather than needing to convince a large group of people to switch to a different room.
Look at freenode for example. It was fairly organized as far as shifting a massive group of communities goes but still quite messy. In the matrix scenario rooms could have moved by simply adding new admin accounts on different homeservers and kicking or demoting all admin accounts on freenode. The users wouldn't have to do anything (except moving away from freenode accounts if they prefer).
>> you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure
> But I don't want to trust my community to someone providing me infrastructure.
I mean, that's always the case in the end, isn't it? Your identity is tied to your server, and that's pretty much what defines the whole thing as being a federation and not P2P (that applies equally for XMPP as for Matrix).
As long as migrating from provider to provider is easy and convenient (which amounts to acknowledging that all providers eventually come and go, what centralized service users are in denial about), I don't see it as being a fundamental issue.
It's also easier to mitigate this aspect in XMPP-world where being your own provider is orders of magnitude easier and cheaper compared to running a matrix homeserver and federating at scale.
Also, talking about infrastructure, the situation is quite worrisome in the case of Matrix, I'd say: only one entity is competent enough (or has enough cash committed) to running large-scale: new vector. And it runs that of matrix.org, kde.org, fedora.org, mozilla.org, …. It also happens to be the one specifying and implementing the (incompletely documented) protocol, conveniently.
>> In practice the room survives in a "split brain" mode where different users see different participants
> Even if this is true (I haven't see it when servers go offline) this sounds like a bug that can be improved over time. Not a reason to give up.
It's a very very hard problem to crack. They've been at it for 10 years across many iterations of the protocol: https://telegra.ph/why-not-matrix-08-07 . I like to think that it can be solved the same way I want to have closure about P=NP, but I also challenge that this is a meaningful and practical approach in this context.
> This is true, as I said users are federated and suffer if their homeserver goes down. But it is a huge difference to be able to set up a second account on a second server and continue participating rather than needing to convince a large group of people to switch to a different room.
Yup, and that's all pretty and neat in theory. In practice it happens every so often that rooms just break for inexplicable reasons, and that people must migrate anyway. Not all members do, because for some, everything still looks like business as usual (happened again few months ago with the 3D Printing space), and trust me, this is much more eventful and disruptive than freenode committing seppuku once every quarter century, or with large XMPP networks going under.
Jaber had something like that 5 years before Matrix: https://xmpp.org/extensions/xep-0289.html but decided it wasn't an avenue worth pursuing, as a non-issue in practice. This is further proven by WhatsApp (which is based on XMPP/ejabberd) and its billion active users: you don't have to shove this complexity into the protocol level when it runs natively on a distributed/federated infrastructure (the erlang VM in this case).
> Matrix rooms are fully decentralized and can survive any servers failing.
In practice the room survives in a "split brain" mode where different users see different participants, the room isn't available to the users whose instance went dark as its no longer hosting their identity, and messages are popping mid history while the state resolution is working hard to reach consensus. When the servers finally come back online, there is a risk of never catching up fully, or worse, for the rooms to remain split forever.
And I adventure a hot take there: this property of staying seemingly online (in a frankenbizarre way) came handy way fewer times in the history of Matrix than for all the incurred complexity reflected in daily bugs, privacy, security, performance issues and inconsistencies.