[Standards] Proposed XMPP Extension: Unique and stable message IDs
georg at op-co.de
Sun Jun 7 18:42:36 UTC 2015
* Daniel Gultsch <daniel at gultsch.de> [2015-06-05 13:01]:
> And I'm currently not really seeing the point of a client adding an id
> since the client can already set the stanza id.
Besides of the MUC-eating-your-message-ID use case there is another one
that was heavily discussed as a possible motivation for client-id:
when a MAM-capable client sends out a message, it needs to somehow
obtain the MAM-ID for this message. Several imperfect approaches are
1) Let the server (or MAM entity) reflect the message to the sender,
with a MID element added. This can happen in the form of a full message,
a carbon, or as a stub message only containing the MID and the original
message id, so the client can relate them. Either way, this will
duplicate the number of messages for local senders.
2) Let the client create the MID element, e.g. by writing into the spec
that the MID element MUST be a UUID. That way, the MAM entity will be
able to just add the message to its archive with the client-generated
MID. However, an evil client could create MID collisions, degenerate
hash-tables to O(N), or simply be broken due to accessing random.org
without HTTPS. Besides, letting the MAM entity generate MIDs might allow
more efficient implementations (i.e. autoincrement-indices).
3) Create a MID generation scheme that can be independently followed by
client and server, i.e. full-jid + stream-id + packet-id. This scheme is
very similar to #2, but the client has less options to game it, and I
don't see significant benefits over #2.
I think these options need to be weighted and one of them chosen before
we can proceed with the MID XEP.
|| http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++
|| gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ ||
|| Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: Digital signature
More information about the Standards