[OTR-dev] OTR version 4 Draft #2

[Ola Bini]

Hi Greg,

> It would be good to look at how all the various packaging systems are
> dealing with the existing libotr.  In pkgsrc, it's libotr, version
> 4.1.1.  Some systems seem to have packages called libotr2 and libotr5,
> or something like that, but I'm not sure why.
Yes, we noticed the same thing. In fact, the whole landscape of
package names for libotr is so confusing, that we realized there was
no way we could call our library anything that ended with a
number. That's why we came up with libotr-ng.

> A big question is if you expect systems to allow building with an OTRv3
> implementation that does v2 fallback.  I think you are heading for the
> old library with the old filename and so versions, and a new library
> with a different name (why ng, vs otr4, because 5 may happen, and ng2
> gets awkward).  The old library will support v2 compat, but the new
> library will only have v3 compat, using the old one in a way that
> doesn't admit v2.  Is that what you mean?
Yes, that's what I mean. Basically, the main entry point for all OTR
messages will always be in libotr-ng - and that piece of code will
dispatch to v3 or v4 depending on what's requested. So the v2 code
will not be accessible from libotr-ng at all. A plugin could in theory
use libotr directly and get access to v2, but I have a hard time
seeing how that could be done in a way that's compatible with ALSO
using libotr-ng.

About the naming - the idea is not that libotr-ng will only be for v4
of the protocol. In fact, let me quickly mention why we didn't do it
all in one library, and decided to create a new code
base. Fundamentally, the v4 spec is a large upgrade to OTR. It changes
a significant amount of things - enough so that the old API wouldn't
be compatible at all. Trying to shoehorn v4 into the v3 API would have
made for horrible code and terrible usability. And since the internals
of v4 are also significantly different, we decided it was cleaner to
implement this completely separately.  As we all know, code complexity
lead to bugs.

But, most of these reasons for creating libotr-ng will not be concerns
for v5 and upwards. We expect the changes in upcoming versions of OTR
to be smaller, and fit well within the concepts of the libotr-ng
implementation, so our plan is that libotr-ng will be the codebase for
several versions going forward.

Hope that makes sense!

> The real problem is that many in-use clients are using old code.  That's
> more of an intrinsic problem than an OTR problem, but OTR is coming
> along for the ride.  I don't really know what to do, other than having
> OTR supporters dig in and help the lagging projects along (or declare
> some of them nonviable).  Given this, there's a tension between
> requiring v3-or-newer only and allowing older things to work for a bit
> longer in the hopes of getting them updated.  Otherwise, we risk two
> clients that both "support OTR" not interworking, and developers
> dropping OTR to avoid this.
This is definitely a problem, and I'm unclear if there's much we can
do to help here, except for pitch in directly on other projects. 

> Without thinking too much, I wonder if the best thing is to let the
> protocol allow v2 (as "MAY") or not allow v2, augment libotr for OTRv4,
> and have a build-time config to enable or not enable v2, leave it
> enabled by default at first -- expecting packagers to take your default
> -- and change the default when you are willing to abandon all systems
> and users that are v2 only.  (If Adium's stable release did v3, I would
> probably not have suggested this.)
Well, as I mentioned above, it's not so easy to "augment" libotr for
v4 support. In fact, if we were to do that, it would lead to
significant differences in API, not to mention code complexity. So,
that would mean that older projects wouldn't get access to the v4
functionality anyway. At least now they can continue using libotr
without any changes for the time being, and then link against
libotr-ng when they are ready to change things.

> > The situation between OTR and OMEMO is a bit complicated. Short story
> > - from my perspective: OTR and OMEMO have quite different viewpoints
> > and perspectives on several things, including supporting networks
> > other than XMPP, support for SMP, stronger AKE's and several other
> > aspects. We, in the OTRv4 team, believe that the choices we have made
> > in the design of v4 will lead to a significantly stronger protocol,
> > both from a purely cryptographic perspective, but also from a
> > usability and deployability perspective. Not speaking for the OMEMO
> > team, but my impression is that they disagree with this belief.
> 
> Thanks.  It would be nice if thre were a dispassionate comparison
> someplace.  In particular the usability issues are very hard (will
> follow up separately on that).
Yeah. We have tried to come up with something like that, but I don't
think we have published it anywhere yet. 

> > There have been interactions with people involved in Conversations and
> > OMEMO at several times. I would characterize those interactions as not
> > being super constructive.
> 
> That's unfortunate.  The removal of OTR from Conversations seemed
> surprising and abrupt to me, but that's all I know.
Yeah, I've heard similar things from other users of Conversations. I
do know that the main developer have been quite unhappy with OTR for a
long time, and have mentioned it in presentations and so on. But there
seems to be very little evidence of this online (it's mentioned in one
or two closed issues, but little else).

Cheers
-- 
 Ola Bini (https://olabini.se)

 "Yields falsehood when quined" yields falsehood when quined.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20180511/9c0859ee/attachment.sig>