On 26 March 2017 at 15:12, Andreas Straub <[email protected]> wrote: > So even if we were to go this way, the timeline until we could in good > conscience actually enable this change in the client is on the order of > many, many months. Because I'm not about to break the protocol for my users.
The 'this breaks current users/implementations' argument seems to come up regularly in OMEMO protocol discussions, and I don't understand why. Current users have a protocol that works: eu.siacs.conversations.axolotl. Nobody is changing that protocol, so it will work indefinitely. Existing users will never be affected. Until it reaches Draft (which can, and probably will indeed take months), everyone should expect 'urn:xmpp:omemo:0' to get breaking changes regularly. This is what 'Experimental' is for. That said, in this case, the argument "The axolotol protocol covers more *situations* than omemo:0" *is* a valid argument. So at that point, I have to ask myself, if we're already in this for the > long haul, why not actually do it right, i.e. explicit server support? If it's a valid technical question to be asked, then it needs to be asked now. Although involving the server in this would make things a bit easier on clients, I'm also concerned it brings more practical problems to rely on server availability than it solves. As you said, even if server implementors decide it is worth investing resources in implementing this custom protocol, it still makes clients rely on their server administrators to upgrade and enable this feature, which they may have less reason to for a purely end-to-end feature. Besides, for end-to-end encryption, relying on the server as little as possible sounds preferrable (although it shouldn't take away any security theoretically). Remko
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
