17 Jan
2025
17 Jan
'25
11:12 p.m.
On 2024/12/23 07:44, Nicolas Cedilnik wrote:
<snip>
In the introduction is written:
"Due to the federated and extensible nature of XMPP it's not possible to
remove a message with full certainty and a retraction can only be
considered an unenforceable request for such removal. Clients which
don't support message retraction are not obligated to enforce the
request and people could have seen or copied the message contents already."
In example 4 there is already a `<fallback>` element.
Concerning setting the body to "/me retracted this message", using `/me`
is a nice touch, but the rest doesn't make sense to me, since that is
not the message being retracted, but rather a previous one, and
non-supporting clients have no way of knowing which one that was. So I
think it can only be something like "/me retracted a previous message,
but it's unsupported by your client."
JC
4. Do you have
any security concerns related to this specification?
Maybe the XEP is not the place
for this, but I would like clients to
make it explicit that this is a "convenience" feature and not a a
security one. Something like "consider anything you have sent
(password, credit card number…) as now disclosed, retracting the
message is not enough" (words are hard). 5. Is the
specification accurate and clearly written?
Yes. I have a minor concern with Example 4 and its body "This person
attempted to retract a previous message, but it's unsupported by your
client.". I believe using a XEP-0428 fallback indication that the body
is a fallback for XEP-0424, and setting this body to "/me retracted
this message" is the way to go — this is how I implemented it in
slidge. ;-)