[Standards] Message Retractions

Maxime Buquet pep at bouah.net
Tue Sep 24 14:29:47 UTC 2019

On 2019/09/24, JC Brand wrote:
> On Tue, Sep 24, 2019 at 10:40:30AM +0200, Maxime Buquet wrote:
> > What about looking at it the other way around? 1:1 being the general
> > case and MUC something that modifies/enhances it.
> > 
> > In 1:1, one would be able to send a retraction, referring to a previous
> > message that has been sent with the same barejid. I think this should
> > also be possible in MUCs.
> > 
> > Additionally in MUCs, one could send an IQ to the room so that the MUC
> > itself broadcasts it to all participants of that room.
> I don't like the idea of there being two ways of doing the same thing in a MUC.
> IMO there should be only one way of doing this,

I think these can/should be taken as semantically different.

One being retracting your own messages. The other being retracting other
people's messages ("moderating a room"). They're essentially not the
same thing to me.

It might have been mentioned before, but it would make sense to split
them. Rename this XEP "moderation" and keep the "retraction" case for
own messages.

A client implementing both will have to use a similar logic as described
below anyway though.

> and given that sending the
> retraction message yourself can cause problems with verifying validity

A client would have to verify the validity of any incoming retraction
message anyway. Having the MUC broadcasting this for you doesn't mean
you're exempt of spoofing attacks.

Here is an exemple of validation logic:

If retraction message (RM) @type is 'groupchat':
- (Moderation) Check if @from is a barejid and equals room barejid, if not
- (Participant retraction) @from is a fulljid.
- Ensure the fastened message (FM) is of the same type.
- If RM @from is a valid room barejid as defined above, stop here.
- RM is a fulljid, ensure RM's fulljid equals FM's fulljid.

If retraction message (RM) @type is 'chat' or 'normal':
- This is not moderation.
- Ensure the fastened message (FM) is of the same type.
- If message is MUC-PM[0], (and client is joined to this MUC?), ensure @from is a fulljid,
  * Ensure that RM @from equals FM @from fulljid
- If not MUC-PM, ensure RM @from equals FM @from barejid.

This is probably not perfect but I think that's a good start(?)

[0]: Indicated by the presence of <x xmlns='http://jabber.org/protocol/muc#user'/>
  or previous knowledge that the barejid is a MUC (a general problem of
  MUC-PMs anyway).

Maxime “pep” Buquet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190924/9625c6c3/attachment.sig>

More information about the Standards mailing list