I've started to use this approach, however, now all messages fetch from MAM from MUC are marked as "read" as by default I mark all messages received from MAM as read. Due to that, we've lost the ability to jump to "unread" messages as we think that all are read. Will need to look into that issue - maybe threat all messages from MUC-MAM as unread by default?

Best would be to use XEP-0333: Chat Markers and use them to mark points to which messages were read. Our clients would "mark" shown messages (as it does now) and sent a marking message to the recipient (or MUC server). That would allow us to keep unread messages in sync between our clients (also in MUCs) and maybe even show in MUC/MIX rooms which messages were read by who?

For now, I've released what we have right now for testing.

After testing it for a while it seems to be working quite good.

I have only one issue though - with xmpp:conversations@conference.siacs.eu room - almost always the next day I only receive messages for that day (after connecting) and history between last message and today's messages are missing. Querying archive manually returns all messages. It looks like today's messages manage to mark "last message" timestamp before Beagle is able to query the archive to retrieve the history.

@wojtek Beagle checks/retrieves timestamp of the last message in the room from the local archive BEFORE it asks to rejoin the room. And after joining it reuses that buffered timestamp, so it is not possible that it would get wrong message.. unless there is another client and our local MAM stores MUC message for that other client (ie. stores private MUC message as they are not groupchat). That behavior could mess up the whole message synchronization mechanism.

There is only one, single client - BeagleIM.

Unfortunately after opening the client I can't catch the XML and what is being requested. Would running Beagle from the console give more details/log regarding the issue?

room: conversations@conference.siacs.eu

you can: disable account, open XML console for disabled account and then enable that account

I've just checked and it looks like it is working just fine (reconnection is sometimes delayed because of the MUC room not answering on a disco#info request).

I just checked it today and your previous guess about lack of response for MAM stanza was correct. Basically, sometimes conversations room doesn't respond to MAM query. (it seems that this was mostly caused by ejabberd's traffic shapers that drop packets: https://docs.ejabberd.im/admin/configuration/basic/#shapers)

I'd say that if there wasn't a reply to query (i.e timeout) it should be retried so we would get complete history.