The OMEMO dev’s push to get many clients to drop OTR support has seriously fragmented the XMPP world :(
It seems like there must be a modern client that supports both OTR and OMEMO, but, I haven’t found one.
deleted by creator
jackline and coyim are two XMPP+OTR clients that are actively maintained/developed, and last I checked there were still some others (plus numerous more that are not being maintained but are still widely used). it looks like the former is open to adding OMEMO while the latter is opposed to it.
in any case there are many people still using OTR on a daily basis; I know people that use separate accounts and clients to talk to their OTR and OMEMO contacts.
deleted by creator
it’s the network effect; if you know a bunch of people using OTR and you switch to something that doesn’t support it then you can’t talk to those people anymore.
When OTR support started going away (as a result of the campaign against it by the OMEMO guy) a lot of people stopped using XMPP rather than adopt one of the OMEMO clients that existed at the time. (In the pre-omemo days xmpp+otr was my primary means of daily communication; today I hardly ever use xmpp at all anymore. 😞)
I am pretty dissatisfied with all of the messaging solutions that are popular today, so I’m thinking about giving OMEMO another shot… but asking around I’m realizing that I actually still might know more OTR users than OMEMO users! (hence the question in this post.)
Poezio still supports OTR, and also supports OMEMO mostly[1].
To be honest I’m also not entirely sure why OTR was dropped. At the time when OMEMO was introduced it may have had a better crypto mechanism (based on Signal’s) but OTR has caught up with this not so long after.
One common argument I hear against OTR is that it is transport-agnostic, and this prevents features from being used and included in the encryption. But the same argument that OMEMO (0.3) prevents features from being used and included in the encryption could have been made when it was first adopted, and it is still the case today while nobody implements the latest spec version (0.8). Hopefully this should change soon.
Note that being transport-agnostic is also an argument in favor for some use-cases, such as gateways. Plug in your OTR addon of choice and chat across various bridges. Otherwise both sides of the bridge need to agree on a common encryption mechanism and a serialization format. I’m not sure there is any other use-case where this (being transport-agnostic) is actually useful though.
UI and trust mangement aren’t there, but one can send and receive ↩︎
Note that being transport-agnostic is also an argument in favor for some use-cases, such as gateways. Plug in your OTR addon of choice and chat across various bridges. Otherwise both sides of the bridge need to agree on a common encryption mechanism and a serialization format. I’m not sure there is any other use-case where this (being transport-agnostic) is actually useful though.
Yeah, there are IRC clients that support OTR for private (1:1) messages, and there are IRC to XMPP gateways… i’ve never done it myself but I have heard of people using cross-protocol OTR that way. I’m not aware of any other cross-protocol e2ee system.
Poezio still supports OTR, and also supports OMEMO mostly
poezio’s OTR support comes from potr which unfortunately relies on pycrypto which says it is “unmaintained, obsolete, and contains security vulnerabilities”. Its its OMEMO support comes from poezio-omemo which uses python-xeddsa which says “This code was not written by a cryptographer and is most probably NOT SECURE”. I haven’t looked very closely but I think python-xeddsa might actually be OK; it has some (barely) post-covid commits and is built using primitives from djb’s SUPERCOP, but pycrypto is definitely dead and should not be used anymore.
