6 ms·

Like “the UX of HTTP is horrible”? Still doesn’t make any sense. Discord could well run on top of IRC the protocol and be open to federation without any change

Like “the UX of HTTP is horrible”? Still doesn’t make any sense. Discord could well run on top of IRC the protocol and be open to federation without any change of UX.

luke5441 3mo ago
IRC doesn't have offline messages and standardized user accounts. Just looked it up and there is IRCv3 to fix this, but idk what the state of that is.
- FireBeyond 3mo ago
  "... not great". 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.
coldtea 3mo ago
>Like “the UX of HTTP is horrible”? Still doesn’t make any sense 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.
oriolid 3mo ago
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 3mo ago
  > Netsplits It's not inherent to the protocol. https://ergo.chat/ https://ergo.chat/ does not have netsplits (from having a single server) and https://github.com/Libera-Chat/sable 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 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 https://ircv3.net/specs/extensions/sasl-3.1)
  - oriolid 3mo ago
    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.
    - progval 3mo ago
      > Replacing the server-to-server protocol sounds a lot like it's not really IRC protocol any more 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.

Like “the UX of HTTP is horrible”? Still doesn’t make any sense. Discord could well run on top of IRC the protocol and be open to federation without any change of UX.

luke5441 3mo ago

IRC doesn't have offline messages and standardized user accounts. Just looked it up and there is IRCv3 to fix this, but idk what the state of that is.

FireBeyond 3mo ago
"... not great". 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.

coldtea 3mo ago

>Like “the UX of HTTP is horrible”? Still doesn’t make any sense 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.

oriolid 3mo ago

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 3mo ago
> Netsplits It's not inherent to the protocol. https://ergo.chat/ https://ergo.chat/ does not have netsplits (from having a single server) and https://github.com/Libera-Chat/sable 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 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 https://ircv3.net/specs/extensions/sasl-3.1)
- oriolid 3mo ago
  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.
  - progval 3mo ago
    > Replacing the server-to-server protocol sounds a lot like it's not really IRC protocol any more 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.