XEP-0424/425 Feedback
Hi, Some feedback while trying to implement these XEPs XEP-0424 1) The schema mentions <xs:attribute name='by' type='xs:string' use='optional'/> But the XEP does not mention the attribute, what is the purpose? 2)
When replacing the original message with a tombstone, the original contents (i.e. the <body/> and any related elements which might leak information about the original message) get replaced with a <retracted/> element which MUST include an 'id' attribute referring to the original message
Why does the element MUST have an id attribute? its a element inside the <message> which already has the id, or in case of groupchat its inside a mam wrapper which has a stanza id, in all cases its perfectly clear that the retracted element belongs to the actual message wrapping it, maybe im missing something obvious here but i dont see a need for this id attribute at all. Example 7
For messages of type 'groupchat', the stanza's Unique and Stable Stanza IDs (XEP-0359) <https://xmpp.org/extensions/xep-0359.html> [4 <https://xmpp.org/extensions/xep-0424.html#nt-idm41385450875712>] 'origin ID' MUST NOT be used for retractions
Example mentions origin-id in groupchat context <message type="groupchat" from="romeo@montague.example" to="lord@capulet.example" id="wrong-recipient-1"> <retracted stamp='2019-09-20T23:09:32Z' xmlns='urn:xmpp:message-retract:1' id='origin-id-1'/> </message> XEP-0425 1)
A Message Archive Management (XEP-0313) <https://xmpp.org/extensions/xep-0313.html> [6 <https://xmpp.org/extensions/xep-0425.html#nt-idm34711750431632>] service MAY replace the contents of a message, that was retracted due to moderation, with a 'tombstone' similar to the one described in Message Retraction (XEP-0424) <https://xmpp.org/extensions/xep-0424.html> [5 <https://xmpp.org/extensions/xep-0425.html#nt-idm34711750445088>].
How similiar? The tombstone text does not mention seemingly important MUST rules from XEP 0424 For example
Some clients may have been offline while the retraction was issued. The archiving service therefore MUST store the retraction message, regardless of whether the original message is deleted or replaced with a tombstone.
the above mentioned MUST rule about the id attribute in the <retracted> element, seems to be not important anymore in moderation, at least the id attribute is not found anymore in the tombstone. Im not saying we need to copy text 1:1 between the XEPs, but should the XEP not go into more detail what exactly the differences are, and what exactly from 0424 applies? Thanks Regards Philipp
Hi Philipp, sorry for the late response. Please see my replies inline. On 2024/04/16 21:31, Philipp Hörist wrote:
Hi,
Some feedback while trying to implement these XEPs
XEP-0424 1) The schema mentions
<xs:attributename='by'type='xs:string'use='optional'/>
But the XEP does not mention the attribute, what is the purpose?
Looks like it's not necessary. I'll remove it.
2)
When replacing the original message with a tombstone, the original contents (i.e. the <body/> and any related elements which might leak information about the original message) get replaced with a <retracted/> element which MUST include an 'id' attribute referring to the original message
Why does the element MUST have an id attribute? its a element inside the <message> which already has the id, or in case of groupchat its inside a mam wrapper which has a stanza id, in all cases its perfectly clear that the retracted element belongs to the actual message wrapping it, maybe im missing something obvious here but i dont see a need for this id attribute at all.
The id on the <message> is not guaranteed to be globally unique and the XEP states that if the origin-id was specified, that should be used with the <message> id as fallback. The idea behind it is to allow clients to identify the original message if it was cached and replace it with the tombstone. One could argue that if you're doing a MAM query, you're doing it for messages you don't already have cached. I think that's true, but I'm not sure I want to remove the ability to find an already cached message from a tombstone.
Example 7
For messages of type 'groupchat', the stanza's Unique and Stable Stanza IDs (XEP-0359) <https://xmpp.org/extensions/xep-0359.html> [4 <https://xmpp.org/extensions/xep-0424.html#nt-idm41385450875712>] 'origin ID' MUST NOT be used for retractions
Example mentions origin-id in groupchat context
<messagetype="groupchat"from="romeo@montague.example"to="lord@capulet.example"id="wrong-recipient-1"> <retractedstamp='2019-09-20T23:09:32Z'xmlns='urn:xmpp:message-retract:1'id='origin-id-1'/> </message>
XEP-0425 1)
A Message Archive Management (XEP-0313) <https://xmpp.org/extensions/xep-0313.html> [6 <https://xmpp.org/extensions/xep-0425.html#nt-idm34711750431632>] service MAY replace the contents of a message, that was retracted due to moderation, with a 'tombstone' similar to the one described in Mess//age Retraction (XEP-0424) <https://xmpp.org/extensions/xep-0424.html> [5 <https://xmpp.org/extensions/xep-0425.html#nt-idm34711750445088>].
How similiar? The tombstone text does not mention seemingly important MUST rules from XEP 0424
For example
Some clients may have been offline while the retraction was issued. The archiving service therefore MUST store the retraction message, regardless of whether the original message is deleted or replaced with a tombstone.
the above mentioned MUST rule about the id attribute in the <retracted> element, seems to be not important anymore in moderation, at least the id attribute is not found anymore in the tombstone.
Im not saying we need to copy text 1:1 between the XEPs, but should the XEP not go into more detail what exactly the differences are, and what exactly from 0424 applies?
I think the main issue is that the id isn't needed for MUCs, but it is needed for 1:1 chats, since 1:1 message IDs aren't guaranteed to be unique. I'm not sure what the best solution is here. The text in 424 can be updated to state that the MUST is necessary only for 1:1 message, but not MUC messages. What do you think? Regards JC
participants (2)
-
JC Brand -
Philipp Hörist