> 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 repeat. 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="r...@muc.example.com/oldhag" to='r...@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='r...@muc.example.com'/> </message> Moderator sends: <message type="groupchat" id='retraction-id-1' to="r...@muc.example.com"> <body>This message contains inappropriate content for this forum</body> <retract id="stanza-id-1"/> </message> 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="r...@muc.example.com"> <body>This message contains inappropriate content for this forum</body> <retract id="stanza-id-1" by="r...@muc.example.com/macbeth"/> </message> 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 message. 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 accomplish. > 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? No. > 5. Is the specification accurate and clearly written? See above & remarks from Marvin. Georg P.S: I accidentally signed my last message to the list <20220104170640.vo2lhw3iit7uy...@boerde.de> with the wrong key. I hereby assure that I was the sender indeed.
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
