Hi,

> From: Sam Whited <[email protected]>
> 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.

Ignat
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to