24 Dec
2024
24 Dec
'24
8:08 a.m.
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"
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.
Marvin