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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > > > >
