Is end-to-end encryption going to be part of a modern IRC experience? Please, this is an absolute must. And don't make it optional if possible. Make non-e2ee optional.
These specifications just capture how the IRC protocol currently operates, so that isn't described here (isn't widespread afaict, and there isn't a clear 'winner' in terms of implementations/mindshare). The issue with something like E2E encryption is getting rough consensus with all the vendors, which is what the IRCv3 WG focuses on: http://ircv3.net/
There's been a number of E2E encryption methods proposed in the past such as SSL/TLS DCC (which doesn't do certificate verification from what I've seen, so that's not too useful here), FiSH and OTR are already used decently out there but I'm not aware of any widely-available, simple-to-implement specification for clients to look at. There's another interesting proposal here, but it hasn't gained traction as of yet:
http://blog.bjrn.se/2009/01/proposal-for-better-irc-encrypti...
There's been a number of E2E encryption methods proposed in the past such as SSL/TLS DCC (which doesn't do certificate verification from what I've seen, so that's not too useful here), FiSH and OTR are already used decently out there but I'm not aware of any widely-available, simple-to-implement specification for clients to look at. There's another interesting proposal here, but it hasn't gained traction as of yet: http://blog.bjrn.se/2009/01/proposal-for-better-irc-encrypti...