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.
signature.asc
Description: PGP signature
_______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
