Unlike most of those things you've mentioned, SignalProtocol (the protocol
and reference libraries) has been extensively studied, audited, and widely
deployed to billions of mobile devices. Other than Signal itself (a few
million users), it's in WhatsApp (1.2 billion users), Facebook Messenger
(1.2
On 6/21/17 4:03 PM, Dave Cridland wrote:
> On 21 June 2017 at 15:35, Tobias Markmann wrote:
>> Here my long overdue summary of recent OMEMO discussions. Feel free to point
>> out errors and what not.
>
> The only thing I'd add is a little history. I might wax a little
> cynical in this.
You le
On 21 June 2017 at 15:35, Tobias Markmann wrote:
> Here my long overdue summary of recent OMEMO discussions. Feel free to point
> out errors and what not.
The only thing I'd add is a little history. I might wax a little
cynical in this.
When I started working with XMPP (I wrote a quick and dirty
Hi,
a practical question: XEP-0277 is based upon Atom (RFC 4287) but doesn't use
the whole spec in the specified use cases. Movim use a or
to attach images: XEP-0277 doesn't talk at all about
that, but it is specified in RFC 4287.
Do we consider that the whole RFC is usable for XEP-0277, or
2017-06-21 19:02 GMT+02:00 Remko Tronçon :
>> 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.
>
>
> I agree, I get the same feeling.
In case you two are not the only ones with th
On Wed, Jun 21, 2017 at 11:30 AM, Ignat Gavrilov
wrote:
> 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
>
On 21 Jun 2017, at 18:03, Daniel Gultsch wrote:
>
> 2017-06-21 18:58 GMT+02:00 Daniel Gultsch :
>> 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
>>
On Wed, Jun 21, 2017 at 12:03 PM, Daniel Gultsch wrote:
> I'm open to comments on whether people think hosting it in the attic
> or on my own web space is the better idea here.
I certainly think it would be better to have it somewhere "official"
(in the XSF's webspace).
I do not see anyone as tr
2017-06-21 18:58 GMT+02:00 Daniel Gultsch :
> 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 t
Hi Ignat,
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.
>
I agree, I get the same feeling.
> As it seems to be the "compromise" to not evolve OMEMO in the near future
> and w
2017-06-21 18:30 GMT+02:00 Ignat Gavrilov :
> 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
> deci
On Wed, Jun 21, 2017 at 10:47 AM, Daniel Gultsch wrote:
> XEP-0001. We have countless - very essential - stuck in
> very low ranks like experimental and draft. This leads to developers
> implementing (and deploying to large user bases) experimental and
> draft XEPs (which they are not really suppo
* Kevin Smith [2017-06-21 16:59]:
> It's a complicated issue, and it's not clear to me that we're being
> particularly stupid,
It might not be clear what exactly needs to be changed to improve the
standardization process. But I think it's very obvious that the result
of the current process is po
Hi,
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
decisi
On 21 Jun 2017, at 16:47, Daniel Gultsch wrote:
>
> The problem here is that XEPs usually don't move up the ranks as it is
> intended by XEP-0001. We have countless - very essential - stuck in
> very low ranks like experimental and draft. This leads to developers
> implementing (and deploying to
The problem here is that XEPs usually don't move up the ranks as it is
intended by XEP-0001. We have countless - very essential - stuck in
very low ranks like experimental and draft. This leads to developers
implementing (and deploying to large user bases) experimental and
draft XEPs (which they ar
On Wed, Jun 21, 2017 at 9:53 AM, Peter Saint-Andre wrote:
> The OMEMO saga (of which I am only a distant observer) raises a more
> general issue: leaving a specification in the ProtoXEP state for way too
> long.
OMEMO is actually in experimental; so I'm not sure this applies to the
OMEMO discussi
The OMEMO saga (of which I am only a distant observer) raises a more
general issue: leaving a specification in the ProtoXEP state for way too
long. I have always been an advocate of accepting a proposal for XEP
publication as quickly as possible, in part to avoid this kind of limbo.
Indeed, in the
On 21 Jun 2017, at 15:47, Peter Saint-Andre wrote:
>
> Thanks for the summary, Tobias!
>
> On 6/21/17 8:35 AM, Tobias Markmann wrote:
>
>
>> With that, the media and client developers can point to the version of
>> XEP-0384 that is currently widely implemented and the XSF community is
>> free
Thanks for the summary, Tobias!
On 6/21/17 8:35 AM, Tobias Markmann wrote:
> With that, the media and client developers can point to the version of
> XEP-0384 that is currently widely implemented and the XSF community is
> free to improve the end-to-end security standard OMEMO in XEP-0384
> with
Hi,
Here my long overdue summary of recent OMEMO discussions. Feel free to
point out errors and what not.
Cheers,
Tobi
Overview
The OMEMO protocol [0, 1] aims to bring end-to-end security to XMPP. It is
currently based on the Signal [2] protocol. At its core it is based on
elliptic-cu
21 matches
Mail list logo
