I am aware that OTR is being rolled back. My point is that extensibility is at odds with practical security and privacy for the vast majority of users. The people who need it the most do not understand the difference between OMEMO and OTR, but I can tell them to go install WhatsApp or Signal, give them a rough idea of why you want one or the other, and everything will be copacetic.
This isn't actually a thing anyone uses; I'm not aware of any non-commercial XMPP clients implementing it. It's just an attempt the IETF had a while back at standardizing E2E. It didn't really work, OMEMO has come much further.
And you don't have to explain the difference between OTR and OMEMO to anyone, just tell them to "Go use Conversations, it's on the Google Play store" and they'll be using OMEMO to speak with you.
> The people who need it the most do not understand the difference between OMEMO and OTR,
For most of them there won't be any difference. Modern clients do not implement OTR so people will not even encounter the term and OMEMO is enabled by default so users don't need to bother with it.
Federated protocols can be made secure, if there are popular, secure by default players on the market. Look at what happened with HTTP2 and TLS 1.3: browsers basically used their powerful position to upgrade the security for the entire federated ecosystem. There are also other minor factors, such as tooling (SSL Labs) that incentivizes people to maintain their servers. And most certainly users of HTTPS don't need to understand how e.g. Certificate Transparency works, that's handled internally by their clients (browsers).
Of course there will always be a niche of low security clients, but who cares that TLS 1.2 doesn't work on some old Java?
HTTP/2 is federated in a sense that the network is composed out of heterogeneous nodes operated by different parties and these nodes communicate with each other (applications running on servers frequently act as clients accessing other HTTP servers).
If calling HTTP/2 federated bothers you I can rephrase my argument:
> Federated protocols can be made secure, if there are popular, secure by default players on the market. Look at what happened with the other IETF-standard protocol: HTTP2: browsers basically used their powerful position to upgrade the security for the entire ecosystem. There are also other minor factors, such as tooling (SSL Labs) that incentivizes people to maintain their servers. And most certainly users of HTTPS don't need to understand how e.g. Certificate Transparency works, that's handled internally by their clients (browsers).
I am aware that OTR is being rolled back. My point is that extensibility is at odds with practical security and privacy for the vast majority of users. The people who need it the most do not understand the difference between OMEMO and OTR, but I can tell them to go install WhatsApp or Signal, give them a rough idea of why you want one or the other, and everything will be copacetic.