14 May
2024
14 May
'24
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?