[Standards] MAM ids on new messages to prevent deduping

Ben Langfeld ben at langfeld.me
Mon May 11 15:46:18 UTC 2015

The thinking is that it is a simple way to provide a baseline method of
stanza disambiguation for all XEPs without reinventing solutions.
Generating a UUID is cheap, and I don't see any reason for a client
implementation to object to doing it.

On 11 May 2015 at 12:36, Brian Cully <bcully at gmail.com> wrote:

> 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> 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/3718f929/attachment.html>

More information about the Standards mailing list