[Standards] XEP-0369: MIX - Forced room ownership

Steve Kille steve.kille at isode.com
Thu Apr 26 07:52:08 UTC 2018


> 
> Okay, I’m not sure if what I’m going to write even makes sense, but I prefer to
> have it stated instead of hindsight later on. I think this feature might be
> problematic, because:
> 
> - Ownership implies responsibility. Adding third parties as owners without their
> consent and a chance for them to reject that ownership (responsibility) doesn’t
> feel right.
[Steve Kille] 

I think that main thing about Ownership is "rights", and so adding ownership is more about granting permission.

I can see that in some channels there is also going to be a responsibility aspect.


> 
> - What is the use for a room without owner? This seems like an annoying mishap
> without real use-cases.
[Steve Kille] 

I can see scenarios where you use MIX channels for automatic distribution.   You manage channels as the system administrator, and there is no benefit to explicitly defining an owner.

In typical MUC room type scenarios, it will be sensible and desirable to have an owner.   


> 
> I *do* realize that we currently do have this situation with MUC to some extent,
> but that doesn’t mean that we shouldn’t fix it. Ownership should IMO require
> consent from the user, just like invitations do. GitHub learnt that the hard way
> [1]. Our case may be a bit less concerning because there’s no way to list all
> rooms somebody has onwership over, so even if I posted some NSFL content in
> an (anonymous?) room called "XY secret dungeon" and then made XY owner of
> that room, nobody would know without me promoting it.
> 
> This is also the case with IRC, even though the fact that the list of persistent
> "owners" of a room is generally not visible alleviates that further; once it is
> visible to third parties that you’re an "owner" (you get
> +ao from ChanServ), it is also visible to yourself and it’s trivial to
> +act on
> that.
> 
> Just a few of my cents.
> 
> I also think that we might be able to bolt this on later to prevent the core MIX
> spec from becoming too large (and also I guess this doesn’t make any sense at all
> in corporate environments). Imagining:
> 
> - Classic request to make user owner fails with forbidden (if it is allowed for
> admins of the MIX service itself) or policy-violation (alternatively, it could
> generate an invitation instead of adding the user right away); instead a new
> request endpoint is provided for inviting a user.
> - Invited user gets a message which requests consent (similar to how MUC
> invitations or moderation requests work)
> - Invited but unresponsive users are tracked in a separate, owner-only (i.e.
> only owners of the MUC can read it) PubSub node.
> - Upon acceptance, invited user is added to the owner list. Upon rejection, they
> are removed from the invited list.
> 
> This of course means there needs to be a way to block such invitations from a
> particular user or from a MIX service; the invitation should probably include the
> originating user and Blocking Command implementations would have to act on
> this.
> 
> kind regards,
> Jonas
> 
>    [1]: https://blog.github.com/2016-05-23-repository-invitations/
[Steve Kille] 

This sort of checking feels a bit OTT to me, and I suspect could really get in the way of some types of operation.

However,  I see that it could be useful/important in some sorts of service, for example one offering openly creatable and accessible channels.

I really don't want to mandate this sort of thing in the core.     

However,  I will place a hook into the text, so it can be developed as a bolt-on XEP later


Regards


Steve




More information about the Standards mailing list