Matrix-doc: 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:

1. 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?