[OTR-dev] OTR version 4 Draft #2

[Carsten Mattner]

On 5/11/18, Ola Bini <list at olabini.se> wrote:

> 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.

What are your ideas/plans for v5, and how do you envision the v4 API
to support those? It sounds like you have a vague vision that would
fit within v4's model.


What do we gain by including v3 support in libotr-ng? Shouldn't we
remove it and avoid complexity? If a client wants to support v3 and
v4, and libotr-ng would link v3's lib, then why shouldn't the new code
path use libotr-ng for v4 only?


Since our last discussion here, I've come to the conclusion that
libotr-ng should really reduce its external dependencies and try to
find a single crypto primitives lib or bundle those that are written
in C or Go anyway. Their implementation doesn't change, and any change
in a crypto primitive is dubious and worthy of a lenghty code and
crypto review anyway.


As you mention the name of lib has been getting confusing, so why not
take the opportunity to use a unique name, rather than libotr-ng?