Yeah it's more about user psychology/ergonomy. A Blunt tool that expose its limit can be preferred to a potentially better one that create more unknown failures. (Not thinking about SDV)

Sure netsplits happen, but at least I can still communicate with people that are on the same side of the split (and know exactly who they are). I never had the same issues as with Slack, Matrix, etc. where I just couldn't communicate at all for > 10 minutes.

And frankly I don't really care about it magically back filling the log later on, since the moment has passed. I value "Availability" above all else. And here IRC is unparalleled.

And improving upon the netsplits without breaking this aspect is really quite difficult.

The whole point of Matrix is you run your own matrix-synapse homeserver, so if the people you know are also connecting to your homeserver, and there's a matrix equivalent of a netsplit, you'll still be talking to those on yours - with the bonus of history backfill when your server reconnects to some other federated server.

Same happening as IRC - but with a different and more resilient protocol.

I also think including Slack along with Matrix is incorrect, as Slack is - like Discord - a centrally controlled walled garden. Matrix is not like those two at all.

That doesn't really help since the home server more corresponds to my irc client (or something like quassel-core or a bouncer) and not a irc server and will just have me as a user and no one else.

The Matrix architecture is much closer to the one used by Jabber Multi User Chat (with perhaps a fancier MUC protocol) than IRC.

That's not true though - you'll still be talking to everyone on every homeserver that yours can reach (or can be reached transitively)! When matrix.org went down for a bit a few years ago, I could talk in the same rooms with everyone on a homeserver that wasn't matrix.org flawlessly, even though the room was first created on matrix.org. I struggle to see how Matrix could be less available than IRC, where I've experienced many more netsplits.

Yes it is possible to mirror rooms, but last I checked that had to be setup manually? Or does synapse do that automatically now?

In any case that wasn't my point earlier. That was that I never had the issue on IRC that my homeserver somehow got stuck for several minutes while it did "something" in the room resolution protocol before suddenly catching up all of a sudden. And that I'll take netsplits any day over it being stuck.

I'm not sure what you mean by mirroring rooms - rooms don't have any one particular home or special server, they exist across all participating servers always and automatically.

I've never experienced what you're describing with the homeserver getting stuck while it did something, though I have had Element Android time out and seemingly not notice for a while & keep spinning, but that was the client's fault, not the server. My best guess is that whatever you experienced did get fixed!

Yes, but you are not syncing between all of them (since that would scale quite badly), but directed graph like in IRC (if I understand the specs correctly anyway). Edit: Oh.. or does it really sync between all servers (in which case I didn't quite understand the spec I guess)? Then that solves netsplits quite well at the cost of quite poor scalability.

Not sure what the issue was in the end, but I have had it with all clients I had tried (mobile, desktop, ..).

I agree that full mesh network is bad for scaling, but IRC's directed graph—manually configured even—is bad for availability. There is some talk about making the routing better, but I guess it's not in near future..

In Matrix it could be a problem, but practically it's not a problem even in the largest room #matrix:matrix.org with probably thousands of servers. But it makes joining that room quite slow and resource intensive.

Of course there is no IRC network with thousands of servers, because accepted hosts are well curated by the rules of the IRC network whereas any Matrix server can join the global federation. Granted, you don't need to join a chat network with an IRC server, but then neither does a Matrix server.

Re: edit, yep I believe it is full mesh sync for homeservers in a room, but if for some reason two can't communicate they can get the graph from other servers. It's eventually consistent if the homeservers are connected through any path, but it tries to be full-mesh. Scalability I think will be tackled to make P2P more practical, though.

Sorry you had that issue!

Incorrect, as you can configure your homeserver to be a public server or an invite-only server where you can have your chums join your homeserver - and thanks to federation even if there is some break in comms between your homeserver and another federated server - say the matrix.org server (which runs on the same matrix-synapse you'd be running) - it's possible for the federation to route around the problem - which, exactly like IRC's netsplit, will resolve eventually, but with the added advantage of synching history.

We are conflating things here, since the architecture of IRC and Matrix are not the same. Since due to the federated nature each room will be different - like it is in Jabber.

I am not talking about talking to my friends (since that's already solved with a private irc network), but for random people on rather large public rooms, where everyone will be isolated to their homeserver without manual configuration (granted.. since we have some big homeservers like matrix.org probably they'll able to continue chatting in the room).

Edit: Turns out I misremembered the federation algorithm from the spec - seems like it is indeed currently full-mesh and not a directed graph so I retract my remark.

Wholeheartedly agree with the above.

Also remembering IRC's netsplits resulting in IRC Services being split off and resultant and inevitable chaos when the netsplits end.

It's not really as much of an issue these days as it used to be.

And like I said.. you can get that all in a neatly integrated package where you don't have to worry about any of that anymore.