16 Apr
2024
16 Apr
'24
1:31 p.m.
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(a)montague.example"
to="lord(a)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
14 May
14 May
10:50 a.m.
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)
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.
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
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
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?
362
days inactive
390
days old
1 comments
2 participants
participants (2)
-
JC Brand -
Philipp Hörist