> * No standard maximum message length. If you input a line which is more than 510 characters after being prefixed with the channel name, server name, and other metadata, it may be truncated for some clients. If you're on a network which includes multiple servers, some clients may actually see your message truncated in different locations, based on how long their local server's name is.
Well, doesn't that mean the limit is 510 characters including the command? I never as an user had issue with this. This is also implementation issue, if you use one server such as you do with slack, then you know its capabilities.
> * No standard text encoding. Some clients assume ISO8859-1, some assume UTF-8, and some will mix and match (ew).
Well, there's a CHARSET value in 005 numeric from the server which declares the official encoding.
> No way to determine when certain commands have succeeded. In particular, commands which can generate multiple lines of output (like WHOIS) don't have a standardized termination. Command-line clients sidestep the issue by just showing all the output in one place; higher-level clients have to guess.
I'm not sure what you're talking about, there's 318 RPL_ENDOFWHOIS numeric:
https://tools.ietf.org/html/rfc1459#section-4.5.2
> No standard identity services. NickServ is a common bolt-on, but it's a total hack. (It works by pretending it's another IRC server!)
You mean it works by pretending that it is another user. The reason for it is an optional component. Some networks (especially the largest one) are running successfully without such services. I kind of like this approach because it leaves the server protocol simple (networks often provide multiple services NickServ, ChanServ, MemoServ etc) and makes the component optional.
> Bold, colors, and emotes (/me) are all client-side hacks.
If you think about it, does it have to be server side? Server is just to relay messages, what they mean is up to a client. In fact pretty much any chat network that allows multiple clients has different looking emoticons. So making it part of the network doesn't help at all with unification.
> DCC file transfer is a complete and utter mess. It's like TFTP, but poorly implemented, over a TCP transport.
HTTP is also over TCP so not sure what you are trying to say here (BTW: TFTP works over UDP).
But ignoring the TCP part, yes DCC feels like it has problem, but that's mainly because of NAT becoming popular. Hopefully as IPv6 is adopted we get back to previous times where ach user had own IP address.
Anyway, comparing DCC to slack etc. Is a bit unfair, because their service is nothing like DCC (Direct-Client-to-Client i.e. P2P) when you upload a file to slack you upload it to their server, but with DCC you're sending it directly to the user without any 3rd party involvement.
Looking at the issues you listed, it feels to me that the problem is not as much with IRC servers, but with IRC clients, in particularly lack of standardization. You could solve most of the issue by defining client protocol on top of IRC, for example:
- handling encoding
- abstracting communication with services
- colors/emoticons
- file transfer (instead of using DCC which sucks with NAT) a client could upload file to a server and provide link to others, emulating behavior of other chat networks
The nice thing about it is that most of this could be implemented in a way that standard clients would still be usable, but if a standard would be created and other IRC clients would respect it, IRC could easily compete with existing solutions.