I like IRC but it's 2018 and even the latest drafts of ircv3 lack built in e2e encryption for private and group messages.
Using IRC is like using ftp or email. We've been there and tried that,slapping on a solution to secure it just won't work well. They've been trying to fix email for decades now and the best solutions we have(gpg and s/mime) still don't provide metadata security (I don't think their encryption can be callend end to end either)
In my opinion, a new end to end encrypted protocol that preserves the properties of IRC people like would be ideal.
If you break backwards compatibility? Maybe to an extent. How do you handle clients that don't support it? How do you secure channels and allow some of the current server op/admin (what freenoders call staffer) functionality? By the time you consider that and more you might as well make a new protocol.
Let's say someone with an older irc client or who doesn't want e2e messages you,what then? Now your irc conversations become opportunistically secure. That means only arbitrary conversations are secure. Email does this and it sucks.
Another problem,clients that don't have e2e almost always also store logs in plain text. Yet another problem - no protocol level e2e plans as of yet.
So why try to fix it? This approach does not work. The least we can do is learn from history. Unlike email or ftp, there aren't a whole lot of people that depend on irc being the current irc protocol. What people want is a distributed server architecture with a user interface that is similar to the current irc. What protocol engineers seem to get wrong is that they use the opportunity to also add other fancy features which simply ends up working against adoption.
I can perfectly see this implemented without breaking backwards compatibility, similar to how we have usermodes for "connected via SSL" and channel modes for "requires SSL".
It doesn't require breaking backwards compatibility because, as far as outdated clients are concerned, they just "can't enter a channel because they lack a required usermode" or "can't send a message to some user because they lack a required usermode".
We only need the spec to define "some way" to do it so clients can announce their support and servers know what to do with the supporting clients.
Then it's up to IRC daemons to provide some modes for it.
Most of my comment was assuming it was implemented with or without backwards compatibility. You are assuming people will slowly move to the e2e version.
People are still writing clients without tls support. Why would you think e2e support will have better adaptability? People will move away from it when they get enough number of messages that require turning it off because the other party does not support it. Nobody wants to join your channel because you need them to have one of a few clients in a very short list in order to join.
We already have OTR (for quite some time now) and matrix has libolm - things aren't and won't change because the best you can practically implement it is using opportunistic negotiation and that is bad security. Best case scenario(imo),20 years from now 95%+ of irc users will use e2e. That is unacceptable when we already have fully e2e chat today. Let's break compatibility and have a separate network for the new secure protocol. At least that way people that move over don't have to look back. When foss projects move to the new network everything else (again,pure opinion) will follow.
Plenty of people use gpg and s/mime too. It only works partially. Partial security is worse than insecurity. Information leaks between your otr conversations and non-otr conversations.(other issues too,but I don't want to rehash my other comment here)
Using IRC is like using ftp or email. We've been there and tried that,slapping on a solution to secure it just won't work well. They've been trying to fix email for decades now and the best solutions we have(gpg and s/mime) still don't provide metadata security (I don't think their encryption can be callend end to end either)
In my opinion, a new end to end encrypted protocol that preserves the properties of IRC people like would be ideal.