On 5/11/18, Ola Bini <l...@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? _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
