OMEMO messages in private MUC do not decrypt after being archived with message archive

[wisheth]

Expected Behavior

In other XMPP clients with message archiving enabled, I can log out of my client and log back in while still being able to view OMEMO messages previously sent.

Current Behavior

Reconnecting to the MUCs in my XMPP account shows me a sea of various "client doesn't support OMEMO" messages in the forms shown by various clients, including for my own messages.

Possible Solution

I wonder if it's something to do with how OMEMO encrypted messages are stored, or if there's nothing in place to decrypt OMEMO messages after the fact; I'm not aware if this extends to other encryption methods as well and, due to the fact that I'm not too knowledgeable on OMEMO/XMPP cryptography in general and the people I use XMPP with aren't that tech savvy, I can't test for myself. There's a chance that this is because I have multiple OMEMO keys on my account, but I doubt that's it.

Steps to Reproduce (for bugs)

1. Open Profanity and /connect to an XMPP account that's in a private MUC
2. Autojoin said private MUC
3. Receive an OMEMO message (this could be one that's sent in before you log in; for some reason those work)
4. /quit
5. Reopen Profanity and /connect again
6. Autojoin said private MUC to a wall of "OMEMO not supported" messages

Context

This makes it difficult to keep a message history with my friends who use XMPP with OMEMO without using another client; I like to have an archive that I can look back on, and this makes it difficult to do that without exposing myself to another host server.

Environment

Profanity, version 0.14.0

EndeavourOS Linux (Arch Linux "Extra" repo)
I see nothing about glib, which was asked for for this section, but glibc is version 2.39-1

XMPP library: libstrophe
Desktop notification support: Enabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Enabled (libgpgme 1.23.2)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.11.7)
GTK icons/clipboard: Disabled
GDK Pixbuf: Enabled

[jubalh]

OMEMO messages can only be decrypted once.
When Profanity receives such a message it decrypts it and stores it in the sqlite DB. When you quit Profanity and start it later again and join a MUC it will load the messages from this DB. There are some things that play into this as well like: MAM. The server I use supports MAM and I have MAM enabled in Profanity, the messages are shown correctly when I join a MUC again.

If you don't have MAM enabled we will receive the last X messages from the server again (limited amount, I forgot the exact number) when we join a MUC. They will be OMEMO encrypted too and we won't be able to decrypt them since it's only possible to do this once. Maybe you are seeing this? I'm not sure right now what we do in this case would have to check the code.

Can you make sure you have MAM enabled? Or use PG UP key to scroll up and (re)load messages from the DB?

[wisheth]

MAM is enabled, but according to the documentation for /mam it's not supported for MUCs. Using PG UP doesn't load anything in these MUCs, even though I know there are previous messages.

[jubalh]

Sorry I was confused.
MUC MAM is WIP here: #1862

[jubalh]

@H3rnand3zzz didnt we implement that we load messages from DB when we scroll up even when MAM is not available?

[H3rnand3zzz]

@H3rnand3zzz didnt we implement that we load messages from DB when we scroll up even when MAM is not available?

The functionality always was there, take a look at a commented version:

        if (first_entry && !(first_entry->theme_item == THEME_ROOMINFO && g_strcmp0(first_entry->message, LOADING_MESSAGE) == 0)) { // if chat is not empty
            if (*scroll_state != WIN_SCROLL_REACHED_TOP) { // if we haven't reached top of the DB yet
                *scroll_state = !chatwin_db_history(chatwin, NULL, NULL, TRUE) ? WIN_SCROLL_REACHED_TOP : WIN_SCROLL_INNER; // update current reach_top_of_the_db state
            }

            if (*scroll_state == WIN_SCROLL_REACHED_TOP && prefs_get_boolean(PREF_MAM)) { // if we reached top of the DB, fetch MAM
                win_print_loading_history(window);
                iq_mam_request_older(chatwin);
            }

So, long tale short, the only time we fetch MAM now is when we reach top of the DB && MAM is enabled. But otherwise, MAM or not, we fetch the data from DB. Also as far as I remember, it always was kind of this way, just without reached_top state, so we always made (sometimes useless) DB request.

P.S. Sorry for the late response, please use other means of communications in the future.