[Standards] LAST CALL: XEP-0425 (Message Moderation)

Georg Lukas georg at op-co.de
Tue Jan 4 17:52:23 UTC 2022

> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Yes, this is a needed use case.

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

No. This has been pointed out by Marvin very well, so not going to

I'm actually torn between the IQ semantics of the XEP and the
message-based semantics of 0308 and 0424. IQ ensures the authorization
of the moderator, but has a rather cumbersome flow requiring significant
differences from 0308 and 0424, and different payload types.

I'd prefer a message-based retraction/moderation, but then everybody
could add a "moderate" element to a MUC message and all recipients would
have to reconstruct the room membership at the time of that message.

What if we would implement a mixed approach, where any moderator can
send an LMC / retraction / flagging message to the room, and the room
service would verify the moderator's permissions and re-send the
respective message from the bare JID of the room (indicating that it is
legitimate) with an additional by=moderator element/attribute stuffed
somewhere, e.g.

Perpetrator sends:

<message type="groupchat" from="room at muc.example.com/oldhag" to='room at muc.example.com/macbeth' id='inappropriate-1'>
  <body>DM me for free magic potions!</body>
  <stanza-id xmlns='urn:xmpp:sid:0' id='stanza-id-1' by='room at muc.example.com'/>

Moderator sends:

<message type="groupchat" id='retraction-id-1' to="room at muc.example.com">
  <body>This message contains inappropriate content for this forum</body>
  <retract id="stanza-id-1"/>

And the room intercepts that, tombstones the original message and
sends an annotated retract from the room JID:

<message type="groupchat" id='retraction-id-1' from="room at muc.example.com">
  <body>This message contains inappropriate content for this forum</body>
  <retract id="stanza-id-1" by="room at muc.example.com/macbeth"/>

This could also work with whatever syntax we figure out for 0424, and it
could work with 0308 with another element indicating who moderated the

A MUC that supports the protocol would reject moderation from
non-moderators, and a legacy MUC would just reflect the moderation
attempts wth @from set to the full JID of the non-moderator.

A receiving client then only needs to ensure that the moderation comes
from the original sender or the bare room JID, which is not too hard to

> 3. Do you plan to implement this specification in your code? If not,
> why not?

Yes, eventually.

> 4. Do you have any security concerns related to this specification?


> 5. Is the specification accurate and clearly written?

See above & remarks from Marvin.


P.S: I accidentally signed my last message to the list
<20220104170640.vo2lhw3iit7uykqj at boerde.de> with the wrong key. I hereby
assure that I was the sender indeed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20220104/b56395e5/attachment.sig>

More information about the Standards mailing list