After carefully reading the current text again, I noticed that there is
conflicting use of requirement keywords:
- In section 3, "It's RECOMMENDED that you include fallback text in the
<body/>, so that servers will archive the retraction and non-supporting
clients can still indicate that there was an intent to retract."
- In section 6.1, "senders MUST set fallback text that describes the
retraction"

I guess the intent of 6.1 is to disallow fallback text that does
anything else than describing the retraction, aka. "senders MUST NOT
set fallback text that describes anything beyond the retraction".

That said, this doesn't make sense in security considerations:
recipients can't base their security assumptions on the fact that
something is forbidden for the sender through specification.

I also am conflicted about the RECOMMENDED in section 3. or
clarification, RECOMMENDED is the same as SHOULD, meaning there may
exist valid reasons in particular circumstances to ignore this
requirement.

I would rather think the other way: there may exist valid reason to
have a fallback in particular circumstances (e.g. in closed
environments or when for some reason you know about the recipients
setup, you can have a message "Upgrade to version x.y to correctly
process messages in this chat"), but the default should be to not do
it, especially if you consider a far future where every client
implements this specification and thus no client would be using that
fallback. Making a fallback a SHOULD is IMO inherently wrong.

The fallbacks I have seen (and the one in the example) are telling the
recipient that the sender intended to retract some message (without
specifying which one) but that it didn't work because the client is not
supported. Often this message is sent without encryption in an
encrypted chat (causing the recipient to display a warning) and in
English language (which may not be a language the recipient can
understand). For the recipient user, this message is completely
useless: It doesn't tell them the intended action of the sender in a
sufficient way and it doesn't tell them how they can fix the situation
of things not working. In practice, the only use of these fallback is
to make people unhappy. [1]

Dino current implementation does not send a fallback, no matter the
circumstances. There seem to be absolutely no negative implications. We
are considering to add a fallback body (in the realm of just "*Message
deleted*") if, and only if, the deleted message is the very last
message in the chat, and then we would also add a matching <replace />.
This gives a good fallback UX for recipients that support XEP-0308 and
a less useless fallback UX for those that support neither.

Marvin

[1] Anecdotal evidence from just a few days ago, in German:
https://friendica.sokoll.com/display/74fe3dc8-336a-9c7e-a1dc-e0e344732034

On Fri, 2026-08-28 at 12:31 +0200, Marvin W. via Standards wrote: