On 29.09.20 17:36, Dave Cridland wrote:
> Note that I sympathise with this argument. However, I would also note
> there are plenty of clients and client libraries which do a perfectly
> good job of generating random ids already, and forcing them into using
> UUIDv4 might be more painful.
How can one random string format be worse than another random string
format? I honestly have hard times to imagine a client that has a
"generateRandomMessageId" function and can't have it generate a random
UUIDv4. Except if the message id is not completely random but also
partially includes other information, like `timestamp + random string`
and the timestamp is then actually used for something (like sorting).
This IMO would be a huge design fail given that IDs are supposed to be
opaque, and I am not sure if we need to cope with broken designs of
existing code for *new* features/improvements.
> OK, and I fully agree that minimizing the number of ids is very useful
> here, but I suspect that servers will always generate their own MAM id
> for (at least) foreign messages.
I agree it should be their right to do that and clients should expect
that to happen, but there should be no *need* for them to generate a new ID.
> You're correct in suggesting that UUIDv4 is something of a mitigation to
> (a) in a well-intended client. I would think that a lookup table might
> work for handling (b) and even mitigating (c), if we simply allow the
> client-selected id to be an alternate to the server-imposed MAM id.
The latest "urn:xmpp:mam:2#extended" features basically require an
id-based lookup table (or otherwise those new filters would probably be
inexcusably slow).
Enforcing UUIDv4 everywhere also has the advantage that those can be
stored and looked-up as the 128-bit integer they are instead of a
string, making lookup table much smaller and thus more efficient ;)
If servers do not enforce that the ID wasn't existing before, receiving
clients have to assume to receive message id's that have existed before.
However as it is now, clients have to be able to handle this already, so
it's at least not getting worse on this end.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
