OMEMO muc read only

[poVoq]

Describe the bug When testing OMEMO muc we noticed that ConverseJS can only read (correctly de-crypted) but not write (encrpted, unencrypted works) in a OMEMO enabled MUC. Other clients work fine.

It looks a bit odd as on the ConverseJS (7.0.6) the message sort of gets send, but greyed out and still visible in the input field:

To Reproduce Steps to reproduce the behavior:

1. make a OMEMO muc (works with Gajim, Dino and ConverseJS)
2. join with ConverseJS
3. See other people writing, works fine and messages get decrypted, you can also see your own writing from other clients
4. try writing message yourself from ConverseJS

Expected behavior It should work :) It works on 1:1 chats btw.

Environment (please complete the following information):

• Desktop or Mobile? Deskop
• Browser [e.g. Chrome, Firefox] Firefox 90 linux
• Converse.js version [e.g. 4.2.0] 7.0.6 latest release

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[rondadon]

I can confirm this issue. 1on1 Private chats are working fine, but in OMEMO Encrypted MUC after lauching a conversejs session the textfield is first active and you can write something in it but when you send it the textfield is greyed out with the message still in the Textbox and the message is not sent into the chat.

[based-a-tron]

This might have been fixed by https://github.com/conversejs/converse.js/commit/d4382fda196d39a911c6d5c688d0eaec5f3cab75, I believe the issue was that converse would try to encrypt messages for users whose true JIDs were unknown (even in non anonymous chatrooms, for some reason), and the code in src/plugins/omemo/utils.js

    const dicts = await Promise.all(devices
        .filter(device => device.get('trusted') != UNTRUSTED && device.get('active'))
        .map(device => encryptKey(key_and_tag, device)));

Would fail. I hotfixed this by changing these lines to

     const dictResults = await Promise.allSettled(devices
        .filter(device => device.get('trusted') != UNTRUSTED && device.get('active'))
        .map(device => encryptKey(key_and_tag, device)));
     const dicts = dictResults.filter(result => result.status === 'fulfilled').map(result => result.value);

But this is far from a true fix. I think the true issue lies somewhere in converse's understanding of what a given user's true JID is, if it is available at all. Even with this hotfix, OMEMO is extremely unreliable in MUCs. Converse seems to somehow lose users keys after some time, causing their future messages to become unavailable. I believe this issue is related to the previous one, of converse being unable to determine true JIDs, but I am not certain. This frustrated most of my users to the point where we all just agreed to not use OMEMO, which is unfortunate. @jcbrand: have you run into any of these issues? Is my theory about converse losing track of JIDs on the right track?

[jcbrand]

@based-a-tron I'm not sure that what you're describing here is the same issue that was reported.

Sounds like something that should perhaps go into a new ticket?

Is my theory about converse losing track of JIDs on the right track?

Sorry, it's difficult for me to say with the information at hand :sweat_smile: