-
Notifications
You must be signed in to change notification settings - Fork 370
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
base: main
Are you sure you want to change the base?
MSC3993: Room takeover #3993
Conversation
proposals/3993-room-takeovers.md
Outdated
|
||
## 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
proposals/3993-room-takeovers.md
Outdated
* 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`) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
- This is relevant if the joined members with the highest power level don't have the permission to change the
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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).
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. |
MSC3993: Room takeover
Adds the ability for one admin to de-promote other admins.
Rendered
Signed-off-by: Christian Paul info@jaller.de