The last time I looked at IRCv3 I was disappointed by how much was an optional extension.
My opinion is that a strong 'minimum' protocol is critical to interoperability and opportunities for federated protocols to function well across providers. I recall that was the main, non XML, reason that XMPP failed. Of course I also dislike XML as a data storage / transmission format.
IRCv3 is written to be backwards compatible so it makes sense to have a ton of optional stuff - considering it is backwards compatible, everything is optional :-P.
And it makes sense, IRC is already out there and has a ton of servers and clients working, you can't split that community based on the client they're using otherwise you're just creating yet another isolated chat protocol like a ton others before it.
I don't really care much about the protocol myself. I'm never going to be speaking "raw IRC" at any point, so why does it matter? I understand that you want to keep protocol simplicity high to make it easier on implementers, but other than just enough to encourage implementation, I don't see the need. We're talking about human chat applications here. Machine chat can use simpler protocols of course, like a light layer atop MQTT, or the existing base XMPP spec.
Yeah but this is such a niche usecase. Also, Matrix uses an HTTP API and almost every language at least has a binding to libcurl, so it's trivial to get something up for Matrix as well. If you're not into the ascetic appeal of writing bytes raw onto a socket, then IRC just seems silly these days.
>> Writing bots from scratch in a new language is more fun when parsing is easy
> Yeah but this is such a niche usecase.
I think the point is that writing anything for anything is simpler, faster, and has fewer dependencies when parsing is easy.
> Also, Matrix uses an HTTP API and almost every language at least has a binding to libcurl.
Certainly there are advantages of using Matrix and it's HTTP compatibility to implement some solutions. However, I can also imagine some projects are best served with a simple protocol with lean libraries that don't incur unnecessary dependencies on HTTP and the related bloat and complexity.
Back when i was in highschool i wrote a few IRC clients just to learn socket programming in Delphi and later C and Java. I always appreciated how easy it is to get a simple client running.
Actually, I have in fact been speaking "raw IRC" quite a few times. Not much anymore but back in the days when working on a new servers it was quite convenient to just telnet irc.x.yz 6667, NICK Hultner, USER Hultner * * * * (don't care for quick sess), JOIN #xyz-help, PRIVMSG #xyz-help Hello, anyone familiar with error Z1 on XYZ?, pong.
That's basically everything you need to know for some basic chat.
I've interacted with IRC servers via telnet a ton of times. But overall I think that era of protocol design is unfortunately long passed (looking at you SMTP)
