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-unsubscr...@xmpp.org > _______________________________________________
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
