Dino: XEP-0384: OMEMO Encryption 0.4.0+

[Neustradamus]

Can you update the XEP-0384: OMEMO Encryption support to 0.4.0+?

• https://xmpp.org/extensions/xep-0384.html
• http://www.aptest.com/standards/htmldiff/htmldiff.pl?oldfile=https://xmpp.org/extensions/attic/xep-0384-0.6.0.html&newfile=https://xmpp.org/extensions/attic/xep-0384-0.7.0.html
• http://www.aptest.com/standards/htmldiff/htmldiff.pl?oldfile=https://xmpp.org/extensions/attic/xep-0384-0.5.0.html&newfile=https://xmpp.org/extensions/attic/xep-0384-0.6.0.html
• http://www.aptest.com/standards/htmldiff/htmldiff.pl?oldfile=https://xmpp.org/extensions/attic/xep-0384-0.4.0.html&newfile=https://xmpp.org/extensions/attic/xep-0384-0.5.0.html
• http://www.aptest.com/standards/htmldiff/htmldiff.pl?oldfile=https://xmpp.org/extensions/attic/xep-0384-0.3.0.html&newfile=https://xmpp.org/extensions/attic/xep-0384-0.4.0.html

PS: Not sure that 0.3.0 was complete before:

• https://xmpp.org/extensions/attic/xep-0384-0.3.0.html

[mar-v-in]

Support for omemo:1 is implemented in the branch feature/omemo1.

[foss-]

Can someone elaborate what the status is for this? It is implemented but kept in a separate branch. But why?

[Neustradamus]

@foss-: OMEMO 0.4.0+ breaks all current OMEMO 0.3.0 clients...
This change must be merged into all clients at the same time...

[fiaxh]

Can someone elaborate what the status is for this? It is implemented but kept in a separate branch. But why?

@foss- It is on a separate branch as a proof of concept. The code is not sufficiently tested yet, among others because it's the only implementation that currently exists. Once it has been tested more thoroughly, ideally also against another implementation, it can be merged.

This change must be merged into all clients at the same time...

@Neustradamus That's not true.

OMEMO 0.7 is indeed not compatible with OMEMO <= 0.3. However, it is possible to support both versions at the same time. Clients that support both will speak the "old" OMEMO with clients that only support the old version and will speak the "new" OMEMO with clients that already support the new version. Once there is a sufficient adoption of the new version, clients can drop support for the old OMEMO version.

[foss-]

Is there a public timeline? How is planning done? Is there an overview of clients and OMEMO version they support?

This is a real world problem slowing down xmpp adoption and should be tackled with priority. Clearly it goes beyond the scope of a single client which makes discussing this difficult.

Linux distro fragmentation adds to the problem: a contact of mine uses ubuntu and that only offers dino 0.1.x so he can't update to 0.2.x and not leave the default distro package path and is worried about future updates or messed up dependencies. This means no OMEMO for our current client constellation.

[licaon-kter]

@foss- that's kinda out of proportions

Every project that wanted OMEMO has it and they're compatible: https://omemo.top

Future OMEMO is slowing down XMPP as much as group video calls or stickers or whatever else everyone thinks XMPP suddenly needs.

Distro? Sad indeed, Debian Stable Backports has 0.2, there are packages for Ubuntu 20.04 and older built by Dino here: https://software.opensuse.org/download.html?project=network:messaging:xmpp:dino&package=dino

Then again... that's not the fault of Dino devs, ask your distro packagers.