[Standards] Don't let today be the day we bury OMEMO
ignat.gavrilov at mailfence.com
Wed Jun 7 18:22:07 UTC 2017
Just that I understand this topic correctly:
The intention is to put the currently implemented OMEMO (a.k.a. siacs OMEMO) into the XEP and then no longer update that XEP and put all effort into OMEMO-NEXT?
What is the reason to not continue develop OMEMO without UX breaking changes (fingerprint invalidation, impossible backwards compatibility), which to my understanding is not desired by some OMEMO implementations and put everything learned on the while that would require UX changes into OMEMO-NEXT? This way we have to UX-break only once (OMEMO to OMEMO-NEXT), which would have caused users to not like OMEMO (and given that at least some users just moved to XMPP because OMEMO, this should be considered an important thing).
I personally like the protocol-breaking, but not UX breaking changes proposed as ODR by strb. It can be implemented with siacs OMEMO in parallel, making it suitable for widespread deployment withing the existing implementations. Of course their might be minor issues within this proposal (I heard there was some issue with what serializing data for signatures), but this can be settled.
Of course it's perfectly fine to put siacs OMEMO into the XEP now to update it with ODR later (once all problems are mitigated) as long as this keeps protocol-breaking only. Switching for XEdDSA to EdDSA does not sound like changing the existing protocol, it sound like creating a new similar one (nobody would ever propose to update the OpenPGP XEP to use OTR instead), so putting this "change" into a different XEP sounds reasonable to me.
I would propose that those people, who think that those who proposed UX breaking changes start putting their effort into OMEMO-NEXT and leave the OMEMO people working on "their standard". No reason to torpedo each other. We could just resolve the split in the community by splitting the XEP - given that no one *wants* to torpedo the other ones standard. (Feedback will still be perfectly possible from each other, but I have the feeling a lot of this is no longer feedback...)
PS: MARLEEN, the "Modern, implementation-Agnostic, Ratcheting L** Easy ENcryption" sounds better than OMEMO-NEXT.
More information about the Standards