Hi, a lot of what Dave said about future proofing spoke to me and I'm starting to think he (and the others) are right.
It makes me wonder if we should work towards making OMEMO a good standard for a more distant future. In the past a lot of valid changes to OMEMO have been dismissed because they can not be implemented right now. What if we put all those changes in? (Element encryption, not using multiple PEP nodes for multiple devices, and so on). It will surely take time to properly define all that. But there is no rush. We have a pretty good thing going with 'siacs-omemo' right now. We can use that for the foreseeable future and switch to a no-compromise OMEMO once it's truly done. We could change the current OMEMO XEP to reflect what is actually implemented right now with 'siacs-OMEMO'. It would become an Informational XEP (or maybe historical). At the same time we start working on 'OMEMO-NEXT'. A new standards track XEP that incorporates all the good suggestions that aren't really viable right now but will be in the future once implementations have caught up. (Like the multiple items in a PEP node for example). I always said that Element-Encryption (stanza-content) is nice to have. It just takes time to define properly. Let's take that time for OMEMO-NEXT. And most importantly we don't have to worry about being Signal compatible with that one and can use crypto primitives that are future proof. I appreciate Remko was trying to make it work with OMEMO Key Agreement v2 but rolling the dice again and again until the key matches some criteria doesn't sound like something that should be in a standard. Client authors who are looking for a short term solution (and can live with the downsides) can implement OMEMO while all the protocol work would go into OMEMO-NEXT. - Daniel _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
