On Tue, 2024-12-24 at 10:52 +0000, Dave Cridland wrote:

I'm curious about the use of origin-id here. I thought from previous discussions we'd decided that origin-id only had value within certain MUC cases; whereas the origin-id is explicitly only for 1:1 messaging here. Does this mean any message to be retracted has to use an origin-id, and (therefore) a client must send all 1:1 messages with an origin-id?

Do we want to make it use the stanza id attribute instead? If not, why not? It seems that XEP-0308 handles this fine without the use of origin-id.

What do existing clients do? Do they all really inject an origin-id for this one case (are there any others?

I think what you wrote does not reflect what is written in the XEP:

- if a message is of type 'groupchat' -> Use "the ID assigned to the stanza by the group chat itself"

- for MUCs, that means to use the XEP-0359 <stanza-id> from the MUC

- if a message is of any other type -> Use "<origin-id> if present, or the value of the 'id' attribute on the <message> otherwise"

So there is absolutely no requirement for <origin-id>, there is only a requirement for MUCs to assign a <stanza-id>.

Regarding XEP-0308 "handles this fine without the use of origin-id", what I wrote in an earlier mail applies: The id in XEP-0308 serves a different goal. It's not meant to be used to identify the message in the history, it's meant to ensure that both entities have the same understanding of which the last message is, so that if for whatever reason the message ends up out of order or at a different client than expected (e.g. recipient client goes offline and message is routed to another resource instead), it won't be misunderstood to edit an unrelated message. The risk of collision is significantly less in that case.