Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC3993: Room takeover #3993

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Conversation

jaller94
Copy link
Contributor

@jaller94 jaller94 commented Apr 5, 2023

MSC3993: Room takeover

Adds the ability for one admin to de-promote other admins.


Rendered

Signed-off-by: Christian Paul info@jaller.de


## Proposal 1 (simplest: `allow_depromotions`)

This MSC proposes an optional boolean `allow_depromotions` to be added to the `m.room.power_levels` state event. Its default value is `false` to be compatible with the current behaviour.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All three proposals currently add the permission to the m.room.power_levels state event type.
As a consequence, anyone who can edit this state event, can take over the room.
This essentially breaks the current truth that no room admin can demote another room admin.

I'm open to other suggestions, like adding a separate state event type, which could be configured to have a separate power level.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if there was an additional room power level higher than admin. The owner power level. This would make the admin power level not the highest and it would be "best practice" or maybe even forced to only allow one account to have this level . The admin power level could be kept the same or it could be set to have all powers except for deletion of the room.

This way there is an account that can remove admins as a last resort but there can be more than one admin and sense they would have all the powers there would be no reason to make anyone else owner.

Copy link
Contributor Author

@jaller94 jaller94 May 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea of one owner is contrary to my MSC.

I want to ensure a room can be continued by other admin accounts, if one admin account becomes untrusted/unavailable.

* An organisation migrates from one domain to another. To avoid having to ask every room admin to demote themselves while promoting their new accounts, they want one account that has the permission to do so.
* To ensure my ownership of a room, I added multiple of my accounts as room admins to a room. One of the accounts is no longer accessible to me and I want to demote that account.

## Proposal 1 (simplest: `allow_depromotions`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is equivalent to #3510, which got rejected?

Copy link
Contributor Author

@jaller94 jaller94 May 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is different from #3510 in the following ways:

  • This PR only allows joined members with the highest power level to demote each other. Members with a lower power level (e.g. "moderators") are not allowed to demote each other.
  • This PR does not change the default behaviour, but makes it a room setting.
    • This is relevant if the joined members with the highest power level don't have the permission to change the m.room.power_levels event. Otherwise, they can enable the setting themselves.

@turt2live turt2live changed the title Add MSC3993: Room takeover MSC3993: Room takeover Apr 5, 2023
@turt2live turt2live added requires-room-version An idea which will require a bump in room version proposal A matrix spec change proposal s2s Server-to-Server API (federation) unassigned-room-version Remove this label when things get versioned. kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Apr 5, 2023
@turt2live
Copy link
Member

@jaller94 when you get a chance, please sign off on this MSC - thanks!

@progval
Copy link
Contributor

progval commented Apr 10, 2023

#3915 introduces a new named power level 150, however, it does not solve the use case of depromoting rogue users.

Neither do proposals 2 and 3 in this MSC, right?


This MSC proposes an optional string array `owners` to be added to the `m.room.power_level` state event. Its default value is an empty array to be compatible with the current behaviour.

Any Matrix user listed in the array can lower (or remove) the power level of any member. They cannot raise their own power level based on this, to prevent an ambiguity of their actual power level.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can an owner also demote another owner?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, an owner can demote other owners, as implied by "any member".


Simplest: It's simple but might not cover more complex use cases. It could be that one wishes to only allow a subset of room admins to take over a room.

Simple: It covers more use cases and also allows a room owner who can demote admins while not being allowed to otherwise change the power levels state event.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if every owner leave the room?

In the case of your example above (with owners having lower PL than admins), what if the admins want to rebel and ban all owners? Though in this case I guess they might as well remove the owner (which does not seem to be forbidden under this spec).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if every owner leave the room?

It becomes a regular Matrix room as we know it today (implying the onwers can't join or manage to be invited again).

In the case of your example above (with owners having lower PL than admins), what if the admins want to rebel and ban all owners?

Admins can rebel. They (in most cases) have the power to ban members (owners don't have a special protection) and remove owners by changing the m.room.power_levels state event.

}
```

* Alice and Bob can not lower each other's power level.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can Alice and Bob remove Delilah from the owners? Who can actually edit that list?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can Alice and Bob remove Delilah from the owners?

Yes, Alice can remove Bob from the list of owners, because with her PL 100 she can replace the m.room.power_levels state event.

Who can actually edit that list?

Every joined member with the PL to set the m.room.power_levels state event.

I did consider adding owners to its own state event, however, it would only make a difference in practice, if owners could be changed with a lower power level (e.g. a moderator being allowed to recover a (half-broken) room where all admins have left).

@@ -0,0 +1,170 @@
# MSC3991: Room takeover
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind of already implied in the "Unstable room version" section, but it could be helpful to make it obvious that each proposed solution requires a new room version (as they are changing the authorization rules of the room).

@jaller94
Copy link
Contributor Author

jaller94 commented May 19, 2023

#3915 introduces a new named power level 150, however, it does not solve the use case of depromoting rogue users.

Neither do proposals 2 and 3 in this MSC, right?

I'm not trying to protect against rogue admins. In my opinion, the Matrix Spec protects well against rogue admins by not allowing demotions.

I want to protect against outdated/untrusted/unavailable accounts which have not maliciously used their power level so far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal requires-room-version An idea which will require a bump in room version s2s Server-to-Server API (federation) unassigned-room-version Remove this label when things get versioned.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants