XSF Discussion - 2022-08-15

A message that only contains an origin-id cannot be quoted in the sens of XEP-0461: Message Replies ?

Same question for XEP-0444: Message Reactions actually

From a MUC, because the origin-id can be send twice by different sources

wah

did you mean stanza-id?

origin-id needs to go away

https://xmpp.org/extensions/xep-0359.html#origin-id

those don't have message@id

what you see in the wild is messages with both message@id and origin-id, with the same big uuid

twice!

ok

should the {urn:xmpp:reply:0}reply@to point to the room itself? ✏

It will take me a few hours to wrap my head again against all those cases, it's pretty complex

It's maybe the 4th or 5th time I'm fixing things

https://xmpp.org/extensions/xep-0444.html#sending-reactions

If <origin-id> is present, can I just avoid to handle <message id=""> ?

Looks like the same thing to me except one of both is a proper UUID

> The message is referred to by including its id or in MUCs its stanza-id as defined in Unique and Stable Stanza IDs (XEP-0359) [4] in the 'id' attribute of the reactions element.

This is the logic for reactions, and for replies its worded differently

https://xmpp.org/extensions/xep-0461.html#business-id

To me both XEPs (message replies and message reactions) should have exactly the same logic Also I'd be happy to simply drop the message "id" part. I think a modern client should be able to handle XEP-0359: Unique and Stable Stanza IDs if they support Message Replies and/or Message Reactions.

Then the logic should be written at only one place and all the XEPs that replies on doing something on a message should rely on that unique logic. To me the logic to ensure that we are replying/reacting to a unique message would be: - If type = chatroom, check stanza-id with a by from the MUC JID - If other type, check origin-id That's it

*that relies on doing something