[Standards] OMEMO Discussion Summary 2017
daniel at gultsch.de
Wed Jun 21 16:58:33 UTC 2017
2017-06-21 18:30 GMT+02:00 Ignat Gavrilov <ignat.gavrilov at mailfence.com>:
> 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.
thank you for taking the time to comment here even though your company
decided to move on (I can't blame you.)
I think the meaning of that compromise is overstated.
The main reason for doing this is that we have a stable version which
can be addressed and linked to (old versions are archived) while
development of the XEP continues. The consensus has been that people
want to make OMEMO into something that goes far beyond what it is now.
That's fine. But this will take time. And it will also invalidate the
audit. That why I want - during the ongoing development of the XEP - a
note on top of the XEP that says. 'Hey you might have heard that OMEMO
got audited and widely implemented. But that's only true for version
0.3 (insert link here). We are actively working on making this XEP
even more awesome (see below) but if you are looking for the audited
and widely implemented version look at version 0.3'
That's all there is to the mysterious compromise. The compromise is
not 'merge my current state of implementation PR and do nothing' but
'merge my PR and then go on the long journey and develop OMEMO further
(and put a warning in there about experimental crypto and such)
More information about the Standards