Should room creators always be able to give themselves power? (SPEC-369)

[matrixbot]

Submitted by @​matthew:matrix.org
Currently if the admins accidentally deop themselves from a room, the room is screwed. Should we special-case whoever created the room to be able to fix that mess?

(Imported from https://matrix.org/jira/browse/SPEC-369)

[matrixbot]

Jira watchers: @ara4n

[matrixbot]

Links exported from Jira:

is duplicated by SPEC-253

[matrixbot]

By @​matthew:matrix.org: An interesting extension could be to formally have the concept of 'founder' or 'ownership', that can be xferred between users, but never de-owned (unlike you can de-op yourself)

-- NEB (Bot)

[matrixbot]

increasing priority given the number of people accidentally deopping themselves and having an orphaned room

-- @ara4n

[Torxed]

I will not argue whether or not a room-creator should be able to jump back in if he or she accidentally left/deop-ed itself. That's a "mistake".

I'll argue in the case where a long lived room has a few admins in it, say 3-6 admins.
And one of those admins goes rogue and starts kicking or banning people hysterically.

This is a situation that none of the channel-administrators can do anything about since they're all of the same power level (they're not allowed to modify self.level >=).

I have two propositions:

1. The database flag admin=true in in the users table could come into play here. Assume we're located on #room:matrix.domain.com, and I'm a user @torxed:matrix.domain.com with the flag admin=true. I could be used as a server moderator and clear up this mess. I could deop the rogue admin, reset all the bans that the rogue admin made and re-invite those kicked out of the channel. (Restricted admin privileges on souly matrix.domain.com owned channels, not federated channels)

2. A kick-vote system, where the remaining admins can do a /vote kick @rogue:matrix.domain.com. Where they all vote yes/no and if a certain ratio of (100/num_of_admins)*(yes/no)>=X is matched, the kick in this example is executed and the rogue admin is removed from the problem.

[ReqX]

I second Torked 1) I think that is mandatory if deploying non federated rooms in e.g. an enterprise environment.

[Torxed]

After discussing with my dear friend, we found a third option:

3. The channel (either as a collective or the moderators+) initiate a /vote kick @rogue:domain, if the vote has a majority decision - any user flagged as admin=true on that particular domain is notified about the task at hand and can first then go in and kick (or deop depending on vote) the rogue user.

This gives the whole situation a double hand-fold on the situation and neither party can single-handedly kick or deop another channel-admin.

While discussing this I realized this is a morph of how StackOverflow does a lot of its community policing, except there a moderator can actually just walk in and remove entire threads (rooms) if they choose to. That will ofc be flagged for suspicious behavior and what not..
But it's a close resemblance to what they do with the voting and moderator policing - except here the admin=true will not be allowed to intervene until a vote is a majority decision - which I think is good.

Side note: The rogue channel admin should probably get any kick/deop/op suspended while a vote is active, also any recent +op (or all?) by that rogue admin should not count into the verdict seeing as he or she might have +op a few friends to keep the scale in favor for the rogue chan adm.

[zzottel]

Re Matthew's concept of room owners: It might make sense to never have more than one owner of a room, otherwise it's just ops part two (in regard to rogue ones). So once I transfer that right to someone else, I lose it myself. The channel owner could be the only one who can always deop others, regardless of their rights, which would also help with the rogue op problem.

If the room owner leaves the room, he still keeps the owner right and will be owner (and op) again once he rejoins. If the owner has left the room, a majority of ops can move the owner right to someone else (and then the old owner will not be owner again when he rejoins, of course). The same could be made possible if the owner's account still exists and is a member of the room, but hasn't been used since X.

And while a voting scheme is implemented, it could also be used to give op to someone in an opless and ownerless room. Something along the lines of "majority of members active within two days" or so.

Not sure if that (especially regaining privilege on rejoin) is even possible, but if it is, I think that approach would make sense.

[ara4n]

Yeah, my suggestion is just to have the concept of a single founder, who can explicitly xfer that status to someone else if they are relinquishing founding status of the room. The idea of voting-based powerlevels is fun but would be a nightmare to implement in the current decentralised model; the business rules for who can do what are already twisty enough, and need to be kept as simple as possible.

[Mikaela]

Currently all the admins are equal, but I am worried about what if the room creator turned rogue in a bigger organisation? I think currently co-administrator could limit the damage in theory even if they wouldn't be able to do anything to the other person.

Atheme IRC Services currently allows 4 founders by default who are equal except that their equality includes the ability for anyone to defounder the other founders and founder anyone else.

[slipeer]

Perhaps, if there is no administrator left in the room, the administrator's rights should be given to the user (one or more) with the highest rank?
This would solve the problem of orphaned rooms. (when the last administrator came out)

[ShadowJonathan]

@slipeer and if there is no "highest rank" (the moderator has left, only defaults are left), should that title/rank go to the oldest-joined person in the room?

[hex-m]

A well established way to deal with "rogue admins/moderators" that was not mentioned is "voting with your feet". Any member of a room knows all the other members and can invite them into a new room with a different distribution of power.

Voting based decisions could be implemented by transferring the creator/owner role to a bot.

[kevincox]

I am strongly against the idea that the creator has magic powers, however I think it is important that there is always someone with ultimate power in a room. This avoids accidentally locking everyone out but also does not allow rouge admins to come back. I see a couple of options (that may be used together)

1. Prevent the only admin from removing their own privileges (they must first give admin to someone else).
   a. One concern here is leaving. Do we want to disallow an admin leaving?
2. The "best" candidate is automatically promoted to the new admin. For example maybe the highest power-level users are implicitly super-admins even if their actual permissions would restrict them from doing something.
   a. This may be confusing because raising your level could effectively demote other admins, maybe this is good or maybe the change should be made explicit (maybe one of the new admins sends the promotion event to the room).
   b. Maybe multiple users is too complex/confusing and ties can be broken by membership age.
3. The "best" candidates can elect a new owner.
   a. Majority vote? Highest vote count with some timeout?

I like 1 but am worried about capturing every way that the owner can leave a room or relinquish their power. Maybe it isn't too hard if we add an explicit "owner" flag. If not 2 seems good.

One major question is if there will ever be a use case for ownerless rooms? I think the benefits probably don't outweigh the risk. Ownerless would mean that you room is to some degree locked in time forever, which is a long time.

I'm not a huge fan of relying on a server admin. I think the concept of server-admin is important, however they shouldn't be required to solve everyday problems like users making a typo and setting their power level to 010 instead of 100 and locking themselves out

[hydrargyrum]

Regarding 1., you can't always prevent somebody leaving. For example, on a self-hosted (corporate) server, where the room admin leaves the community (company). Their access is permanently revoked. Nobody can control the room anymore. Maybe nobody was even moderator on that room.
A different situation, imagine on a public server, an unfortunate event where the room admin has an accident and can't use a device.

[kevincox]

In that case I think you can still prevent leaving. What would likely happen there is that the new admin would remove the old admin from the rooms and the ownership would be transferred to someone new. This is likely the best solution because in many cases no one remembers who created some chat room and who happens to be the admin. It causes a lot of pain when that person then leaves the company and their rooms, documents... are locked because they are ownerless. It does require admin intervention in this case but I think that makes sense for that sort of environment where you are getting kicked out of a server.

It isn't perfect, but I'm not sure what other options there are.

[hydrargyrum]

I don't understand, how does the new admin become an admin?

[kevincox]

I am talking about corporate environments. I'm assuming that an admin can be injected. (Otherwise how would you force the old admin to leave anyways?)

[hydrargyrum]

I am talking about corporate environments

Great, me too.

I'm assuming that an admin can be injected

How to do that?

Otherwise how would you force the old admin to leave anyways?

When somebody leaves the company, their access is blocked at the upmost level, like LDAP for example, or globally to matrix server. Server admins don't go room by room to kick them. Thus the user leaves every room at the same time, sometimes leaving no other room admin behind.

[JeanPaulLucien]

If admin leaves room and he was not the last user, room should be stay.