The practical problem is that a lot of power-users have strong opinions about which e2e scheme to use in which case. That may include "none". [1] If you enforce a single e2e scheme (no matter which), you will lose a lot of potential power-users, who would double as multipliers to spread your app.
I don't say that Conversations (and the XMPP community at large) couldn't do better, though. For example, there could be a standardized, automated, transparent process for determining which e2e schemes are supported by the clients involved in the conversation.
[1] For example, I skip e2e when talking to my several XMPP bots. They run on the same host as the XMPP server, so e2e won't reduce my attack surface when I already have TLS enforced along the way, but make the bot implementation considerably more complex.
> you will lose a lot of potential power-users, who would double as multipliers to spread your app.
Not really. I consider myself poweruser in many areas, but I would never recommend most of my tools to "ordinary" friends. The tools for them should be easy to use and difficult to misuse.
I don't say that Conversations (and the XMPP community at large) couldn't do better, though. For example, there could be a standardized, automated, transparent process for determining which e2e schemes are supported by the clients involved in the conversation.
[1] For example, I skip e2e when talking to my several XMPP bots. They run on the same host as the XMPP server, so e2e won't reduce my attack surface when I already have TLS enforced along the way, but make the bot implementation considerably more complex.