Omemo errors

[dca00]

On one hand, the release 14.0.0 seems to have fixed an old problem whereby some accounts could only communicate one-way. Now, they can also send, not only receive.
But I am getting this error when I try with Omemo on:

They get my messages in their Pidgin, but I get the above error in Converse.

[jcbrand]

That error means that the other device (i.e. Pidgin) did not encrypt the message for the device on which your receiving that error.

What likely happened is that since 14.0.0 you got a new device id / bundle. Converse republishes its new devicelist + bundle to PEP, but Pidgin (lurch plugin) caches the old devicelist and never re-fetches, so Pidgin encrypts to Converse's old device id, which Converse can no longer decrypt. Converse's own messages still go out to Pidgin's known device, hence the asymmetry.

I asked an LLM to explain how you can try and verify this yourself in the devtools console:

---

So the thing to verify first is: is Converse actually publishing the current device and bundle to PEP? If yes, a spec-compliant peer would pick it up via the +notify PEP push, and the fault lies with Pidgin.

Check procedure (browser devtools console)

Note Converse publishes to both namespaces: legacy eu.siacs.conversations.axolotl.* and urn:xmpp:omemo:2:*. Pidgin/lurch is legacy-only, so the legacy nodes are what matter here.

1. Turn on stanza logging, then reload: converse.env.log.setLogLevel('debug')
   // or load with the URL hash #converse?loglevel=debug

Right after login you should see two cyan outgoing <iq type="set"> stanzas and matching goldenrod type="result" replies:

• <publish node="eu.siacs.conversations.axolotl.devicelist"> (item id current, containing a <list> with your device id)
• <publish node="eu.siacs.conversations.axolotl.bundles:<device_id>">

A result reply (not an error) confirms the server accepted the publish. Watch also for the warning api.pubsub.publish: Not publishing via PEP because it's not supported! — that would mean the server rejected PEP entirely.

2. Confirm your own device id and that it's in your published list:

await converse.api.omemo.getDeviceID()
const dl = await converse.api.omemo.devicelists.get(_converse.session.get('bare_jid'), true)
dl.devices.pluck('id')   // your current id must appear here

3. Force a republish if either stanza was missing or errored:

const dl = await converse.api.omemo.devicelists.get(_converse.session.get('bare_jid'), true)
await dl.publishDevices()               // re-publishes the devicelist
await _converse.state.omemo_store.publishBundle()   // re-publishes the bundle

Re-watch the console for a clean result.

4. Cross-check from the peer's perspective (what Pidgin should be seeing). Fetch the reporter's own node fresh, and inspect Pidgin's list too:

// our own published bundle for our current device:
const me = await converse.api.omemo.devicelists.get(_converse.session.get('bare_jid'), true)
await me.get(await converse.api.omemo.getDeviceID()).getBundle()   // returns a bundle → published OK

// what devices Pidgin has advertised for itself:
await converse.env.utils.omemo.getDevicesForContact('pidgin-contact@host')

Interpreting the result

• Publish IQs return result, own id is in the list, and getBundle() on the current device resolves → Converse is doing its job correctly. The problem is on Pidgin's side: it's holding a stale devicelist/bundle and not honouring the PEP +notify push (or
  not re-fetching on encrypt failure). Remedies live on that end: in Pidgin/lurch, clear the OMEMO cache / re-add the contact / restart so lurch re-reads eu.siacs.conversations.axolotl.devicelist, or have the reporter avoid regenerating keys.
• A publish IQ returns error, or the current id is missing from the list, or getBundle() rejects → the fault is on the Converse/server side (PEP node access model, precondition-not-met, or the store never publishing). In that case the fix is here, and
  the error stanza (e.iq.outerHTML is logged with the "unexpected error" alert) will pinpoint it.

---

If you paste the readable error text and the two cyan publish IQs from the debug console, that will settle which side it is.

[dca00]

We don't have this issue with any other permutations of clients, so this clearly points at 'which side it is'.
One idea for your team is to look through the source code of other clients, ex. Pidgin or Conversations, to see how they are able to get it right.

[kicken]

While working on trying to get a new desktop app version out, I've run into some issues with encryption and pre-existing accounts on Openfire. It seems to be a similar issue as last time I look at it where Converse.js is unable to publish it's new device ID in the device list. Unfortunately I've not had enough time yet to dig into it enough to determine if it's an issue with Converse.js, Openfire, or something else.

Starting with a fresh account seems to work fine, so I think it might be some issue with how the account was setup in an older version of Converse.js (or some other client).

[dca00]

Organizations like mine, with 10s of 1000s of accounts go, ah...
I tested your theory and created a brand-spanking-new account. When it sends to me, it gets:

Cannot use end-to-end encryption because user@xmpp.yourdomain uses a client that doesn't support OMEMO.

ConverseJS v. 14 (your latest) on both ends. Basically, your lock icon has only one effect: communication breakdown.
Can you talk to the server developers? They have a support forum. If you explain to them that their server has a problem, they might listen to you and fix it or at least tell you how to work around it. Because this is becoming silly.

[kicken]

I did a little investigating into OMEMO stuff today and I found one problem related specifically to Openfire, but could possibly affect other servers. Openfire doesn't support using max as a value for max_items in the node configuration. The new omemo2 code assumes this is supported. According to a comment in the source, the XEP mandates setting this parameter to max. Whether a server supports doing this can be determined via discovery, and is done in the bookmarks plugin

What ends up happening in this scenario is Converse.js is able to publish the urn:xmpp:omemo:2:devices node, but unable to publish the urn:xmpp:omemo:2:bundles node. This seems to get Converse.js into a state where you can enable encryption on a chat, but the process fails because the bundle cannot be found for the recipient.

I see two possibilities for improving this:

1. Since the XEP mandates support for max, if the server doesn't support it, then disable OMEMO2 support entirely or
2. Similar to the bookmarks plugin, if the server doesn't support max, pick an arbitrary high number instead.

[dca00]

Talk to them.
Explain to them that their implementation is causing problems for you.
Don't just sit silently in your silo. This is how problems are being created and perpetuated.
They do not bite. They are developers just like you. They will understand your lingo.
We, your users, cannot talk to them efficiently because we do not understand anything that you write above. We do not have qualifications for that.