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.