nesium
commented
7 months ago Hey Valerian. So you'd basically want a limit parameter, right?
What I'm currently wondering is if we should implement a more general catch-up method when the client comes online, essentially moving the functionality you're describing into the core.
As mentioned in the OMEMO XEP…
If an OMEMOKeyExchange is received as part of a message catch-up mechanism (like Message Archive Management (XEP-0313) [5]) and used to establish a new session with the sender, the client SHOULD postpone deletion of the private key corresponding to the used PreKey until after the catch-up is completed. If this is done, the client MUST send an OMEMO encrypted message with empty SCE payload right after the key exchange is completed, to forward the ratchet and to move away from the possibly double-used PreKey. This practice can mitigate the previously mentioned race condition by preventing message loss.
So we'd need a catch-up at least for OMEMO encrypted conversations (although you wouldn't know who sent you an encrypted message before catching up).
When a connection is established the core could automatically download the latest N messages for each sidebar item. The client might prioritize the order by calling a provided method for a selected sidebar item.
valeriansaliou
I'm currently implementing the view of the app centralizing all unread messages. For each unread SidebarItem, I'm loading the last desired Nth messages from MAM, based on the unreadCount (capped using a minimum and a maximum).
I'm currently relying, successfully, on
room.loadLatestMessages(), which is sub-efficient in my use case since I'm only interested in the N last messages for each loaded room (potentially, a lot of them if you have a busy Prose workspace).Would it be possible to pass some RSM data in the MAM loader?