MSC3510: Let users kick/ban/demote each other

[ara4n]

Rendered

Preview: https://pr3510--matrix-org-previews.netlify.app

[Mikaela]

On this requiring a lot of education should this pass, there is documentation around such as GNOME's Sovereignty on a Federated System: problems we faced on GNOME’s Matrix instance: Losing ownership which has prompted vector-im/element-meta#290 and possibly a couple of other issues, which may lead into further confusion.

[Mikaela]

I imagine discovering there are 10 different kinds of rooms in the wild can come as a confusing surprise especially to less technical users who simply wish to have their community on Matrix.

The solution to this could be https://github.com/matrix-org/matrix-doc/issues/2564 and similar changes to deprecate the older room versions first before this change and having a proper flow for upgrading rooms instead of the current /upgraderoom which says it's an advanced operation that shouldn't be needed?

[Ai-rin]

Back in Jabber days this behavior caused many troubles. One wrongly chosen admin could easily take over the entire chatroom. The idea of separate owner field in m.room.power_levels sounds much better for me.

[274below]

I am coming from this perspective: matrix-org/synapse#11433

Broadly speaking, there needs to be a way to kick (or demote) maximum-level accounts. My driver is technical: there's an admin (priv 100) account in a room that is associated with a server that doesn't really exist anymore. As a result of the current setup, it literally cannot be removed from the room. This is a technical problem that needs to be fixed through technical means (in the form of either this or some other MSC).

Fundamentally, there always needs to be an "owner" role that has complete access to the room, and that needs to include the ability to manage who is/is not in that "owner" role. Anything short of this introduces long-term technical gaps, which are a problem today (which is something that I'm trying to solve for my setup).

There's a lot of discussion here about the social dynamics of allowing room owners the ability to kick other room owners as well as the potential for abuse. Every time I try to address that point here I wind up writing something of a novel that I eventually wind up deleting. So, instead of trying to address every little point that has been brought up in the above comments, I will simply say that I personally view the potential for abuse in the form of room takeovers to be approximately equal to scenarios where an abusive individual cannot be removed. What's worse: a scenario where a hostile individual takes a room over and makes whatever seemingly malicious changes they wanted to make, or a scenario where a hostile individual who cannot be kicked opts to just delete everything?

I don't think there's necessarily a right answer to which scenario is worse, and I don't see a lot of value in trying to figure it out because the end result is exactly the same with or without this MSC. Without this (or a similar) MSC, priv 100 accounts can just delete the content, rendering the room unusable. With this MSC, priv 100 accounts can evict anyone/everyone that they don't like. Trying to weigh "unusable room due to admin abuse variant A" against "unusable room due to admin abuse variant B" is meaningless when the end result is still "unusable room due to admin abuse."

With all of that said, maybe a middle ground would be only allowing accounts with priv 100 access to either kick or demote (thus allowing a kick) each other; any other level of access below 100 should not be allowed to kick (or demote) accounts with the same (or higher) levels of access. This would minimize the potential for down-level abuse, and provide room owners with a technical means of solving technical problems.

[richvdh]

@Mikaela, @Ai-rin, @274below: please remember to make any comments on the "files changed" tab (https://github.com/matrix-org/matrix-doc/pull/3510/files), otherwise it becomes impossible to track which comments are still relevant.

I'll go through and hide the unthreaded comments so if you still feel your comments are valuable, please re-make them on the "files changed" tab.

[ara4n]

@mscbot fcp close

In retrospect I hadn't thought this through properly at all - thanks all for the constructive review. I've opened #3915 as a replacement, which looks to almost entirely match @su-ex's comment at https://github.com/matrix-org/matrix-spec-proposals/pull/3510#discussion_r761836336.

[mscbot]

This FCP proposal has been cancelled by https://github.com/matrix-org/matrix-spec-proposals/pull/3510#issuecomment-1289480658.

Team member @mscbot has proposed to close this. The next step is review by the rest of the tagged people:

• [ ] @dbkr
• [ ] @uhoreg
• [ ] @turt2live
• [x] @ara4n
• [ ] @anoadragon453
• [ ] @richvdh
• [ ] @erikjohnston
• [ ] @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[richvdh]

The "fcp close" process is normally used when we decide to close someone else's proposal. Since @ara4n is the author, we don't need an FCP on closing this.

[turt2live]

@mscbot fcp cancel

just to clean up the state machine