[I’m worried that my original message is getting derailed here, but
I’ll continue with this thread for a little longer]
Even were it simple, you cannot trust clients to generate UUIDs for
purposes such as MAM or any other “trusted” ID source. It becomes trivial for
ill-behaved or malicious clients to do things like rewrite history, for
instance. You can guard against that, but now you need to ask every server
implementation /and/ every client implementation (including random web clients)
to guard against it in any number of situations. I do not think that is a
reasonable request.
If you want trustable UUIDs then, minimally, they have to be generated
on your XMPP server (federated servers likewise cannot necessarily be trusted
in the same way that your local XMPP server can).
-bjc
> On 11-May-2015, at 11:46, Ben Langfeld <[email protected]> wrote:
>
> 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]
> <mailto:[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]
>> <mailto:[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]
>> <mailto:[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
>>
>
>
