[Standards] MAM ids on new messages to prevent deduping

Brian Cully bcully at gmail.com
Mon May 11 15:36:53 UTC 2015


	I don’t think it makes sense to require clients to generate globally unique IDs. In a closed environment you can do what you want, but it seems onerous to require that for arbitrary clients (many of which don’t include any ID on messages, let alone globally unique ones).

-bjc

> On 11-May-2015, at 11:31, Ben Langfeld <ben at langfeld.me> wrote:
> 
> Leaving backward compatibility concerns aside, I'd like to see globally unique message IDs made compulsory instead of optional and to use the original message ID as the MAM ID. This is what we are doing in our closed-client environment and it works well, but sacrifices compatibility with other clients.
> 
> On 11 May 2015 at 12:25, Brian Cully <bcully at gmail.com <mailto:bcully at gmail.com>> 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 include the stanza that indirectly generated the MAM request, leading to two copies of the stanza in the message view between JID1 and JID2.
> 
>         Note that while the common case would be the most recent stanza being duplicated, it is also possible for more than one to be duplicated because of the asynchronous nature of the MAM IQ response and they may arrive interleaved with new messages.
> 
>         By showing the MAM ID on newly generated inbound messages, the client would be able to ask MAM for all messages before that ID, preventing duplication while allowing new messages to be correctly shown in order.
> 
>         Querying MAM by message times also will not work, given the potential differences in clocks between arbitrary clients and the MAM store.
> 
>         Thoughts?
> 
> -bjc
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150511/09d981f9/attachment.html>


More information about the Standards mailing list