|
|
|
@ -0,0 +1,111 @@
|
|
|
|
|
# MSC0000: Power level up! Taking the room to new heights
|
|
|
|
|
|
|
|
|
|
Once a room is created, the highest power level is set in stone. Even if you're the only
|
|
|
|
|
admin in the room, if you try to raise your own power level above the initial `100`, it
|
|
|
|
|
just throws a `403 Forbidden` error:
|
|
|
|
|
|
|
|
|
|
`PUT /_matrix/client/r0/rooms/{roomId}/state/m.room.power_levels` -> `403 Forbidden`
|
|
|
|
|
```json
|
|
|
|
|
{
|
|
|
|
|
"errcode": "M_FORBIDDEN",
|
|
|
|
|
"error": "You don't have permission to add ops level greater than your own"
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
This is dictated by the [authorization rules (auth
|
|
|
|
|
rules)](https://spec.matrix.org/v1.5/rooms/v10/#authorization-rules) around
|
|
|
|
|
`m.room.power_levels` in a room:
|
|
|
|
|
|
|
|
|
|
> 9. If type is `m.room.power_levels`:
|
|
|
|
|
> [...]
|
|
|
|
|
>
|
|
|
|
|
> 8. For each entry being changed in, or removed from, the `users` property, other than the `sender`’s own entry:
|
|
|
|
|
> 1. If the current value is greater than or equal to the `sender`’s current power level, reject.
|
|
|
|
|
> 9. For each entry being added to, or changed in, the `users` property:
|
|
|
|
|
> 1. If the new value is greater than the `sender`’s current power level, reject.
|
|
|
|
|
|
|
|
|
|
It's possible to have power levels greater than the default `100` (Admin) power level
|
|
|
|
|
but this has to be specified at the time of room creation.
|
|
|
|
|
|
|
|
|
|
Not being able to adjust the max power level of `users` after the fact means that any
|
|
|
|
|
mistake is baked into the room forever and requires a room upgrade to rectify the
|
|
|
|
|
situation. Sometimes, more flexibility is needed in the power level ranges and this only
|
|
|
|
|
becomes obvious with hindsight.
|
|
|
|
|
|
|
|
|
|
For example with the [Gitter
|
|
|
|
|
migration](https://blog.gitter.im/2023/02/13/gitter-has-fully-migrated-to-matrix/), we
|
|
|
|
|
synced all Gitter room admins over as users with a power level of `90` and set the power
|
|
|
|
|
level to do any action at `90` so the bridge bot user could maintain a higher power
|
|
|
|
|
level than the rest of the users while giving the room admins autonomy over everything.
|
|
|
|
|
Then later after the migration, we wanted to clean up the power levels and grant room
|
|
|
|
|
admins the true `100` power level to avoid clients labeling `90` as a "Moderator"
|
|
|
|
|
instead of "Admin". But discovered this was impossible to get right because we couldn't
|
|
|
|
|
raise the power level of the bridge bot above `100` to still maintain a higher power
|
|
|
|
|
level. This condundrum is tracked by https://gitlab.com/gitterHQ/gitter.im/-/issues/4
|
|
|
|
|
|
|
|
|
|
Something like [MSC3915: Owner power
|
|
|
|
|
level](https://github.com/matrix-org/matrix-spec-proposals/pull/3915) could help in a
|
|
|
|
|
situation like this to formalize the position of owner but doesn't help with the
|
|
|
|
|
flexibility of an existing room. For example, imagine this MSC lands before MSC3915, it
|
|
|
|
|
would be nice to just upgrade your room power levels to reflect the new owners role. And
|
|
|
|
|
going beyond MSC3915, it can be useful to set a user/bot above `150` at a later date.
|
|
|
|
|
Imagine wanting a central company bot to maintain control of every room at power level
|
|
|
|
|
`200`. It would be nice to just update your room power levels to achieve this than have
|
|
|
|
|
to upgrade every room.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Proposal
|
|
|
|
|
|
|
|
|
|
This MSC proposes updating the room event auth rules to allow for raising the `sender`'s
|
|
|
|
|
own `users` power level above the current max power level as long as you update all
|
|
|
|
|
others at the same level to the new max level.
|
|
|
|
|
|
|
|
|
|
This means that if you're a solo admin in the room, you can arbitrarily raise your own
|
|
|
|
|
power level however you want.
|
|
|
|
|
|
|
|
|
|
If there are multiple admins in the room, then you must raise all other admins to the
|
|
|
|
|
new max power level.
|
|
|
|
|
|
|
|
|
|
Propsed new auth rule language:
|
|
|
|
|
|
|
|
|
|
> 9. If type is `m.room.power_levels`:
|
|
|
|
|
> [...]
|
|
|
|
|
>
|
|
|
|
|
> 8. For each entry being removed from the `users` property, other than the `sender`’s own entry:
|
|
|
|
|
> 1. If the current value is greater than or equal to the `sender`’s current power level, reject.
|
|
|
|
|
> 9. For each entry being added to, or changed in, the `users` property:
|
|
|
|
|
> 1. If the new value is greater than the `sender`’s current power level and the `sender` *doesn't have* the highest power level in the room, reject.
|
|
|
|
|
> 1. If the new value is greater than the `sender`’s current power level, the `sender` *has* the highest power level in the room, but doesn't raise everyone else with the current highest power level to the new value, reject.
|
|
|
|
|
|
|
|
|
|
Because this MSC changes the authorization rules of a room, it requires a new room
|
|
|
|
|
version to ensure all participating servers are authorizing events and state
|
|
|
|
|
consistently.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Potential issues
|
|
|
|
|
|
|
|
|
|
*None surmised so far*
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Alternatives
|
|
|
|
|
|
|
|
|
|
Room upgrades allow for creating a new room where you can initially specify
|
|
|
|
|
`m.room.power_levels` as desired. There is nothing restricting the integer range that
|
|
|
|
|
`users` field of `m.room.power_levels` so all of the same end results can be achieved
|
|
|
|
|
this way. This has all of the flexibility downsides mentioned for existing rooms in the
|
|
|
|
|
intro/context paragraphs above though.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Security considerations
|
|
|
|
|
|
|
|
|
|
Changes to auth rules requires careful consideration of how things interact and the
|
|
|
|
|
language should be explicit in what's allowed/rejected. Please review the proposed
|
|
|
|
|
changes for holes in the logic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Unstable room version
|
|
|
|
|
|
|
|
|
|
While this feature is in development, the proposed behavior can be trialed with the
|
|
|
|
|
`org.matrix.mscXXXX` unstable room version and `org.matrix.mscXXXXv2`, etc as we develop
|
|
|
|
|
and iterate along the way.
|