[Standards] MAM ids on new messages to prevent deduping

Florian Schmaus flo at geekplace.eu
Mon May 11 15:58:30 UTC 2015


On 11.05.2015 17:25, Brian Cully wrote:
> 	In implementing MAM in clients there can be a case where MAM results contain duplicates of already seen messages. In order to prevent such duplication, the MAM ID for a stanza would need to appear on a newly generated non-MAM stanza.
> 
> 	As background, imagine a client which, when it receives a new stanza from a server, presents a view that renders the new stanza and then queries MAM to provide a chat history between two JIDs. When the JID1 sends a message to JID2 it is logged in the MAM store and forwarded on to JID2, JID2 then requests MAM results for JID1, returning the last 50 messages, which would inc
lude the stanza that indirectly generated the MAM request, leading to
two copies of the stanza in the message view between JID1 and JID2.

I'm not sure if I would MAM to mandate that the client's XMPP server has
to inject a unique (within the scope of the users server and MAM
archive) message ID into the message stanza that is going to get
delivered to the client.

The "inject id" solution is also not ideal. What if there where messages
between the last time the client retrieved the archive and the now
received message (containing a unique message/MAM ID)? Think especially
of a multi-client/session scenario.

I guess what I would do if I had to implement a client:

1. Retrieve message stanza
2. Display message in UI
3. Query MAM archive for messages since the last query
4. Update the UI: Append all messages received since the start of 3. to
the MAM query result of 3. and show the resulting messages in the UI.

From there on you could just display incoming messages in the UI without
querying the MAM archive. Of course there is a possible race condition
which could lead to messages getting displayed twice, but at least you
don't loose messages.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150511/c6c5f76a/attachment.sig>


More information about the Standards mailing list