* Daniel Gultsch <dan...@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 possible: 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. Georg -- || 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 ||_________________________________________________||
signature.asc
Description: Digital signature
