[Standards] OMEMO Discussion Summary 2017

Ignat Gavrilov ignat.gavrilov at mailfence.com
Wed Jun 21 16:30:03 UTC 2017


I'd like to add a comment here (my final one).

I somehow got the feeling that some people on this mailing list actually don't want the OMEMO standard to evolve, when it does not include the changes they want.

Even though the Andy's ODR proposal is not generally in conflict with the decision to move away from XEdDSA and/or to a solution based on two keys, the "compromise" suggests to move back to an older (the currently implemented) step in the XEP evolution.
The only reason I can imagine for this to be proposed by someone, is that they fear that their changes will be off-the-table, once ODR is in place. I don't think they are generally off-the-table, but I guess it will be a lot harder to argue for them, because ODR strips any direct relation to the libsignal library that is not liked (due to license or whatever) by those persons.
I also see a lot of arguing based around the existence of (liberally licensed) libraries. Please consider, that once we (the client devs) have a proper standard, we can and will implement it even without using libsignal. The existence or non-existence of a (liberally licensed) implementation of a properly specified encryption scheme shouldn't be a major reason for decisions. It is valid to talk about, but the time (and money) invested talking about it already exceeded the time required to implement it.

I already started with the note that this will be my final comment on this issue. I don't care about the actual outcome anymore, because we (company) did the decision to just stop waiting for standardization to continue and implement something non-XEP-y (mostly around the ODR proposal). We are running a non-federated, custom-client system anyway, but we would have liked to implement a standard and not a custom protocol. As it seems to be the "compromise" to not evolve OMEMO in the near future and we have a roadmap to finish e2e-encryption by end of the year, there was no choice left then to go this step.
We might release some of our non-libsignal-based development later this year as open-source, but I bet it will be GPL licensed and not under one of those "make money with third-party software and run away with it"-licenses that are so much liked by some of the people (representing their companies interest) here.


More information about the Standards mailing list