On Tue, 24 Dec 2024 at 15:09, Marvin W <xmpp@larma.de> wrote:

Hi,

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"

Ah, I see this in 5.1, but the third para in section 3 says origin-id. So maybe fix that para?

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

Also 5 says that clients SHOULD put in an origin-id "to make them suitable", and that's certainly a requirement (albeit not an absolute one).

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.

Gotcha, though in either case, it's the same client that {retracts|edits} the message as has sent it (and presumably chosen the id), so if it cannot figure out a sensible strategy for generating ids, it presumably can't generate origin-id's any easier. Or is there some other reason why origin-id is less prone to collision?

Overall, then, I'd rather strip origin-id from the spec.

Dave.