Discord could well run on top of IRC the protocol and be open to federation without any change of UX.
It's not inherent to the protocol. https://ergo.chat/ does not have netsplits (from having a single server) and https://github.com/Libera-Chat/sable replaces the server-to-server protocol to eliminate netsplits as well.
And even when not eliminated entirely, they are infrequent and barely visible on well-managed networks like Libera.Chat. Many chat platforms have more (and longer) outages than Libera has netsplits.
> missed messages
Solved by most server implementations using https://ircv3.net/specs/extensions/chathistory
> bot wars over channel and nick ownership
Solved decades ago thanks to NickServ and ChanServ (though I'll admit they are ad-hoc additions on top of the protocol). And ~15 years ago we got native support for authentication (https://ircv3.net/specs/extensions/sasl-3.1)
There hasn't been a standard server-to-server protocol in like three decades. Even RFC 2813 only specifies one of the protocols in use at the time (IRCnet's). Each implementation has its own (some of them forked from the original)
> The chathistory link says "This specification may change at any time and we do not recommend implementing it in a production environment."
True. Ratification of the final spec is stuck on some details, unfortunately.
IRCv3 missed the boat by years. By 2016, when the working group was formed, IRC was already well past its glory years. Even then, it took til the 2020s before any major network fully adopted it. Because - and I say this as a nerd who held an O line on two of those major networks at one point in my life - a bunch of nerds got hung up on arguing about implementation specs rather than looking at features and functionality organically. Ironically, in the quest to avoid becoming a closed Discord/Slack/what-have-you ecosystem product, they needed a product manager to remind them that what they needed to build in that working group was an evolution to IRCv2, not endless arguments over the format of configuration files for server daemons, for but one example.
> And ~15 years ago we got native support for authentication (https://ircv3.net/specs/extensions/sasl-3.1)
The IRCv3 WG was convened near the end of 2016, so 9 or so.
Because people invested/wasted their energy into building proprietary silos instead.
SASL support in IRC predates IRCv3.
Just looked it up and there is IRCv3 to fix this, but idk what the state of that is.
IRCv3 was already late to the party and when I saw that the Working Group's mailing list was composed of lots of debates on formats for server daemon configuration files, it was clear many couldn't see the forest for the trees.
Sure it does, when all browsers have more or less the same, and the context makes clear we're not talking about the mere programmatic consumption of HTTP (like through some REST api).
"But it's a protocol and not a client" is pedantically irrelevant, given that the clients for that protocol all follow the same conventions. The parent already said they meant the UX of it "which is arguably similar between implementations".
Besides, protocols impose some concepts and models of interaction and consumption, which informs any UX created on top of them. So it's not like that client sameness is merely accidental and unrelated to the protocol either.