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

Jonas Wielicki jonas at wielicki.name
Tue Apr 24 07:43:32 UTC 2018


On Dienstag, 24. April 2018 09:09:22 CEST Steve Kille wrote:
> I agree that explicit is good.   It is also clean if you want to create a
> room without an owner or with owners not yourself.

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.

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

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180424/ea328a2a/attachment.sig>


More information about the Standards mailing list