[Standards] XEP-0384: Rejecting? [Was: Re: Proposed XMPP Extension: Ephemeral Messages]

Ralph Meijer ralphm at ik.nu
Thu Jan 2 16:47:34 UTC 2020

On 02-01-2020 16:51, Sam Whited wrote:
> On Thu, Jan 2, 2020, at 15:39, Dave Cridland wrote:
>> So I should accept your assertion that it is possible, but not
>> Philip's assertion on this list that it is not?
> You should, because I have done so and shown that it was possible. At
> the time you insisted that it didn't count because I had clearly copied
> code from libsignal and it would therefore be encumbered in the same
> way, and I pointed out that it was copied from NACL which is public
> domain (libsignal also had clearly copied from here as all the comments
> and much of the code was identical to NACLs).
> I'm not sure why we keep having this discussion. It's been done.

Look, I haven't been following this as closely as some of you, I'm sure. 
However, from what I understand, there are a number of issues here:

  * There's no (public) specification of the actual protocol behind 
Signal (yet?).
  * libsignal cannot be used in non-GPL applications.
  * Re-implementations of the protocol cannot be said to implement the 
Signal Protocol and/or are considered derivative works of libsignal.
  * The protocol itself might receive changes and tracking libsignal is 
the only way to know.

So the problem is not whether or not the protocol could be, or has been, 
implemented independently through reverse engineering. Rather, what the 
XSF needs here, is a protocol specification that for the entire feature 
meets Objective 4 in XEP-0001.

The preference here is a document published by the Signal authors, maybe 
through the impending Signal Foundation. Then, XEP-384 can point to it 
and anyone can go and implement OMEMO without having to worry about the 
issues mentioned above.


More information about the Standards mailing list