On 5/25/17 12:31 PM, Vanitas Vitae wrote:
Hi!
Am 25.05.2017 um 10:47 schrieb Dave Cridland:
Rightly or wrongly, there are other benefits of using Olm, such as
interoperability with Matrix, the availability of existing low and
high level libraries, etc.
Correct me if I'm wrong, but there is still no java implementation,
right?
There is http://matrix.org/git/olm/tree/android, which provides JNI
wrappers around libolm for use in Java. In general this is preferable
(performancewise and auditwise) to a native Java implementation.
There's also someone in the community shifting the build from being
android/gradle to generic Java, although this isn't exactly a lot of work.
In terms of the general question of libsignal-* versus Olm: it's worth
noting that using precisely the same ratchet for both Matrix & XMPP
doesn't necessarily buy much, given the payloads put over the ratchet
will end up being inevitably different. The main advantage of doing so
would be to just benefit from the audit & ongoing maintenance work
that's going into Olm, as well as the more liberal licensing.
But if OMEMO-using-libsignal has critical mass already, I completely get
the concerns over disrupting the existing ecosystem over 'just' a
licensing issue, and perhaps the work would be better spent writing an
liberal-licensed ratchet which is absolutely 100% compatible with
libsignal (including XEdDSA) etc. This could be by extending/forking
Olm to use XEdDSA, or if you're feeling completely masochistic, a whole
new implementation. Then folks on OMEMO-using-libsignal would be able
to talk happily to folks on
OMEMO-using-liberal-licensed-DR-implementation, and everyone's happy (i
think?)
For the record, if someone did jump through the hoops to make Olm talk
XEdDSA we'd probably consider using it on the Matrix side (both to avoid
a fork, and to help pool crypto resources between XMPP & Matrix, and
keep compatibility with folks who want to use GPL-licensed libsignal, etc).
(In other news, I saw Remko mention elsewhere that an advantage of Olm
might be using Megolm-style semantics for XMPP. I'd caution that Megolm
is very much experimental still, and we're not sure all the design
decisions are optimal. More importantly, it's completely decoupled from
Olm, despite the name, and could be layered on top of a
libsignal-managed 1:1 channel just as much as an olm-managed one).
M
--
Matthew Hodgson
Matrix.org
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
