[strkek]

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.

[badrabbit]

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.