[Standards] Don't let today be the day we bury OMEMO

Ignat Gavrilov ignat.gavrilov at mailfence.com
Wed Jun 7 20:00:19 UTC 2017


> From: Sam Whited <sam at samwhited.com>
> In theory this is the purpose of "experimental" XEPS, but in practice
> I think people mostly just get confused about what the "recommended"
> spec is and get annoyed that there are two specs with duplicate
> functionality. I personally don't like the idea of having multiple
> XEPs with the same or heavily overlapping purposes for this reason.

If you consider two technically different encryption schemes "duplicate functionality", then why is OMEMO not a duplicate of PGP-OX, OpenPGP (the old one) or even OTR?
IMHO a new encryption scheme change should be a new XEP or this will confuse users even more (why should I have two OMEMO keys (one siacs omemo for legacy clients and one latest xep key)? How often do you want to do UX breaking changes to the encryption scheme in a the same protocol?

Either deprecate *all* other encryption schemes or don't call different encryption schemes duplicates. Just choose a different name for OMEMO-NEXT in a second XEP and there won't be any confusion. OMEMO is not the name for "encryption over XMPP" but the name for a very specific encryption scheme over XMPP and this certainly includes XEdDSA, a single key for encryption and signing, ... This design decision may not be perfect, but they were already done. Changing that is what will cause confusion. I guess that if OMEMO was never given that name, but was just called "SignalProtocol via XMPP", we won't have any discussions. And if I remember correctly, this was the GSoC project that ended up in OMEMO was about in first place (back then called axolotl).

Also, please note how I differentiate between UX and protocol breaking changes here. Everything a XMPP client can handle under-the-hood by implementing two versions of the protocol is not a problem for user experience, changes that require to generate new identity key material certainly are.


More information about the Standards mailing list