Call me crazy, but I think your example illustrates one reason why IRC is great: I can read it. And I could probably get it right even typing it from memory.
The IRC protocol is surprisingly difficult to implement correctly. I'm not an expert on the issues involved, but a few of the high points include:
* 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.
* No standard text encoding. Some clients assume ISO8859-1, some assume UTF-8, and some will mix and match (ew).
* 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.
* 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!)
* Bold, colors, and emotes (/me) are all client-side hacks.
* DCC file transfer is a complete and utter mess. It's like TFTP, but poorly implemented, over a TCP transport.
Agree about DCC but lot of the other issues you list are due to curmudgeonly (IMHO) users insisting on using non-modern clients and networks.
If they would tolerate a little breakage of backwards compatibility, the big networks could easily move to utf8 with standardized identity and colours, etc.
Unfortunately there is a small but very vocal faction of IRC users that are highly entrenched and resistant to change.
At the same time, that existing base of legacy IRC clients and servers is the only reason it could be worth hanging on to the old protocol. If we're going to break backward compatibility, we might as well take the opportunity to fix all of the other long-standing issues with the protocol.
I still have hope for the IRCv3 project, it appears to be fixing a lot of the issues mentioned. I'm on Matrix, but until #debian moves, I'll be found on Freenode and OFTC.
That was true a few years ago, but is long invalid, due to many recent changes. Nowadays it looks like this:
> * 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!)
SASL and account-notify.
> * 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.
Batch messages.
You can find more at http://ircv3.net/, there’s a lot of specs on modern IRC features. IRC has changed a lot, you might want to take a look at it again ;)
> * 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.
> 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.
> Well, doesn't that mean the limit is 510 characters including the command?
No. The limit is on what the server sends to other clients when a message is delivered. For instance, if you send:
PRIVMSG #channel :some long message
the server will proceed to send everyone else in that channel something along the lines of:
:your@hostmask PRIVMSG #channel :some long message
which will be limited to 510 characters (512 minus CRLF). Unless you're perfectly aware of how the server will render your hostmask, there's no way to know where the limit will end up.
(I incorrectly said earlier that the prefix is based on the server -- it's actually your client hostmask.)
> HTTP is also over TCP so not sure what you are trying to say here (BTW: TFTP works over UDP).
DCC file transfers work on a chunk-by-chunk basis. The sending client sends one block of data at a time, then waits for an acknowledgement before sending the next one. (This is why I describe it as being like TFTP.)
Re: message length, this does still sound like a limit on the implementation, and you could easily make IRC servers that have either longer messages (ircv3 has 1024) or no limit at all (although perhaps that's not a great idea)
> DCC file transfers work on a chunk-by-chunk basis. The sending client sends one block of data at a time, then waits for an acknowledgement before sending the next one. (This is why I describe it as being like TFTP.)
You're right, I was not aware of the acknowledgments. But this in previous response I said that a lot of issues could be fixed on a client side. DCC is also completely implemented with clients and similarly can be fixed this way. There apparently is already DCC XMIT standard which fixes latency caused by the ACKs (assuming our client wouldn't do same thing as Slack does which is upload files to S3 and share the URL)
Agreed that the IRC line protocol is superficially easier on the eyes, but it's far from intuitive (especially the weird USER command). Whereas remembering the URL shape for Matrix is... just another URL (plus you can always cheat and just 'copy as curl' from a browser's network inspector). But each to their own :D
