[Standards] XEP-0369: MIX - Forced room ownership
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
- 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 . 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards