Ola Bini <l...@olabini.se> writes: >> > I'm in principle fine with dropping v2 support. I wouldn't mind a quick >> > look-around at what OTR implementations still don't support v3, though. >> > pidgin-otr does, of course. What about Adium? Others? >> >> By dropping support, is this about removing it from libotr? I am not >> quite following standard vs reference implementation vs ?
> Actually, the way we have thought about this is from the specification > standpoint. Our current OTRv4 has fallback to OTRv3 - but it doesn't > include any facility for falling back to v2. We followed the pattern > that the OTRv3 spec used for this. I see - that indeed makes sense. > I would also argue that removing support for v2 is about time - v3 > adds several things that are quite important, and there are several > parameters in v2 that are too small for my comfort. > > About implementations - we are currently working on a library called > libotr-ng - which will be the production level implementation of > OTRv4. It does _not_ contain full support for OTRv3 - instead, it > links the old libotr implementation for that functionality. Hope this > clarifies things! 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. 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? 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. 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.) >> Conversations has dropped OTR support, leaving OMEMO. I am unclear on >> the relative merits of OMEMO and OTR, but I've been an OTR user for a >> really long time (<= 2005), so I have a pro-OTR cultural bias and >> would like to see it succeed. I wonder if anyone for otr-land has >> engaged Conversations about this. > > 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). > 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. Thanks for answering my questions so thoroughly. _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
