[Standards] Message Retractions

JC Brand lists at opkode.com
Tue Sep 24 16:35:35 UTC 2019


On Tue, Sep 24, 2019 at 04:29:47PM +0200, Maxime Buquet wrote:
> 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.

Ok, Ge0rg made the same point.

> 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.

Ted Sterr suggested this as well.

I'm ok with that, this lets me focus on the moderation case for now, which is
what I need to implement.

> 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.

This covers the non-anonymous MUC usecase. For semi-anonymous we'll need to
check the XEP-0421 occupant id as well.

> 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



> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20190924/49511605/attachment.sig>


More information about the Standards mailing list