I generally like the idea of the MUC assigning the id to it's outgoing messages instead of using the id proposed by the occupant sending the message.
I also think that if we all agreed that we want that, we could migrate to that situation in a backwards-compatible manner: the #stable-id feature, although required by the current version of XEP-0045, is still considered optional for most clients. Removing it and instead adding a #unique-id feature that announces the exact opposite feature (id's are guaranteed to be unique by the MUC) would thus be possible. Some clients send <origin-id/> in messages to MUCs that don't do #stable-id, so just reflecting that to those is going to work with those clients. And if there is no <origin-id/> the MUC could add one in its reflected message to tell which message id the original sender had. For compatibility you would still add a <stanza-id by=muc@server id=muc-assigned-id/> using the same id that is already in message id- attribute. eventually we'll be able to phase that one out. Marvin PS: Having #stable-id and #unique-id at the same time is still feasible. Yes it requires the MUC to store all ids it ever generated (or at least over a longer period), which may sound like it would need a lot of storage, but in fact this can be done somewhat reasonably in constant-size using math™: https://en.wikipedia.org/wiki/Accumulator_(cryptography) On Fri, 2023-02-24 at 15:47 +0000, Tedd Sterr wrote: > I think there may be some confusion and we're not even disagreeing > about the same things; so, I'll state my thoughts more clearly. > > The original sender of a message stanza SHOULD give it id=UUID. > Unfortunately, this wasn't a requirement in the RFCs, so now we have > various hacks to try to deal with that because we can't just fix the > problem while maintaining compatibility. > > In the case of MUC messages, the original sender IS the MUC, and not > the client. The client sends its message to the MUC, and that message > SHOULD have its own unique id, but the message which the MUC forwards > to participants SHOULD be a new message with its own new unique id. > But the client wants to cross-reference the message it sent with the > one it receives, and so the MUC SHOULD also insert an origin-id with > the client's original message id (only in the message it forwards to > that client.) > > Now, the above SHOULDs are my own preferences for an ideal world > where we could have nice things, whereas in reality we maintain > compatibility and add 'just one more' id in the hope it solves > things. > > In the above ideal world, MUC message ids can't be spoofed because > they are assigned by the MUC itself. The MUC doesn't even need to > care what id a client used because it assigns its own new id to any > messages it sends - if a client does duplicate one then it only > confuses itself in the origin-id (and nobody else sees that.) I > understand that is effectively what you're trying to address with > stanza-id, and it is a valid solution. > > What I'm less sure of is the benefit 'by' actually brings in > practice. If there are multiple stanza-ids then it obviously serves > to differentiate them, but why the need for multiple? The client's id > is the origin-id (so it can cross-reference with its archive) and the > MUC's id is the stanza-id (so it can be referenced for reactions, > etc.) Carbons shouldn't need yet another id. > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
