Netsplits, missed messages and bot wars over channel and nick ownership were an integral part of IRC UX, and they were direct consequences the IRC protocol. If Discord was run on top of IRC protocol, it would have the same. Discord would probably be its own network and the people who prefer IRCnet, EFnet or QuakeNet would never touch it.

▲

progval 5 hours ago | parent [-]

> Netsplits

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)

▲

oriolid 4 hours ago | parent | next [-]

So... Usually it's claimed that one of the advantages of IRC is that it doesn't depend on a single server, so using a single server feels a bit like cheating. Replacing the server-to-server protocol sounds a lot like it's not really IRC protocol any more. The chathistory link says "This specification may change at any time and we do not recommend implementing it in a production environment." right on top. And yes, NickServ and ChanServ exist on some networks and IIRC they were one of the major points in debates over which network is the best and which ones to not touch with a ten feet pole. A hypothetical IRC-based Discord-like service could have it.

▲

FireBeyond 2 hours ago | parent | prev [-]

I mean the word "Relay" in Internet Relay Chat was meant to refer to relaying between servers. Larger networks even had some hub servers that didn't allow users to connect at all, and existed to be server interchanges.

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.

	▲	47282847 an hour ago \| parent [-]
		> IRCv3 missed the boat by years Because people invested/wasted their energy into building proprietary silos instead.