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.

Sign up for GitHub

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

MSC3991: Power level up! Taking the room to new heights #3991

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

MSC3991: Power level up! Taking the room to new heights #3991

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
ce21322
Add proposal for raising a power level above current limits
MadLittleMods Apr 4, 2023
32b7bcb
Use MSC number
MadLittleMods Apr 4, 2023
dec22ac
Note alternative for Gitter specific case about specing power level l…
MadLittleMods Apr 5, 2023
d3e8aa6
Better wording on Gitter alternative
MadLittleMods Apr 11, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
124 changes: 124 additions & 0 deletions proposals/3991-increase-power-level.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,124 @@
# MSC3991: Power level up! Taking the room to new heights
MadLittleMods marked this conversation as resolved.
Show resolved Hide resolved

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
MadLittleMods marked this conversation as resolved.
Show resolved Hide resolved

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.
Comment on lines +59 to +61
Copy link
Contributor

Choose a reason for hiding this comment

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

At the same powerlevel or higher or if they have the highest PL.

You also want to check, that there is no event, that requires a higher PL than any user entry. You also need to check that users_default is less than or equal the highest user PL, same with all the other possible powerlevels (redact, notify, etc).

Copy link
Contributor Author

@MadLittleMods MadLittleMods Apr 5, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

At the same powerlevel or higher or if they have the highest PL.

Can you propose a suggestion block? I don't think this is accurate or I can't quite pick it apart to see how it applies. But do think that paragraph could be clearer.

You also want to check, that there is no event, that requires a higher PL than any user entry. You also need to check that users_default is less than or equal the highest user PL, same with all the other possible powerlevels (redact, notify, etc).

I assume you're trying to plug the hole where if you have an admin and moderator in a room and the admin removes their power level, the moderator could boost themselves to an admin or above?

This isn't the above case but keep in mind, that only the top-most power level people can raise their power level further. If there is an admin and moderator in the room, the moderator can't go above their current power level. Only the admin can. This solves any problem of events and various fields being at different PL's.

I think your language is an option but the other side also opens up a different possibility. It kinda relates to matrix-org/matrix-spec#165. If we leave it as-is, people would be able to self-service and solve this problem which represents the hole mentioned above:

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?

-- @slipeer, matrix-org/matrix-spec#165 (comment)

(leaving the room is not the same as removing power levels though)


This means that if you're a solo admin in the room, you can arbitrarily raise your own
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd be a bit careful with using the term "admin" here (and instead say PL50/PL100 or PLMax). Admin means PL100 in Element yes, but that's a dirty hack in the client and not represented by all of them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

"Admin" is just being used as the understandable example here. The situation can occur at any power level (whatever is the highest in the room) so "PLMax" is kinda the only alternative. Not sure it would make it more clear but it would be more correct. More trying to convey the idea in these sentences.

Copy link
Contributor Author

@MadLittleMods MadLittleMods Apr 14, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

We could add some preface sentence like MSC3993,

For this proposal a "room admin" is a user with the highest power level in a room. For the use case this MSC addresses, a room must have two or more room admins.

Adapting that to say perhaps:

In this proposal we use the term "admin" as stand-in example for the user(s) with the highest power level in a room.

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.
Copy link
Contributor Author

@MadLittleMods MadLittleMods Apr 5, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

Is "highest power level" ambiguous? For example, I'm trying to say if the sender has 100 along with other admins in the room or is the only admin

Better language welcome for any of this 🙏

> 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. But this has all of the flexibility downsides mentioned for existing rooms in
the intro/context paragraphs above though.

---

As an [alternative that could solve the Gitter specific
case](https://gitlab.com/gitterHQ/gitter.im/-/issues/4) where a user with a power level
of `90` appears as "Moderator" when it actually functions as an admin role; this could
be solved by spec'ing out how to figure out what is the admin PL and what is the
moderator PL. Hardcoding random integers to labels just doesn't work well. For example,
with the [Nheko](https://github.com/Nheko-Reborn/nheko) client, it considers people with
the permission to change powerlevels to be admins and users with redaction permissions
are moderators. Or maybe something more flexible like [MSC3949: Power Level
Tags](https://github.com/matrix-org/matrix-spec-proposals/pull/3949).

This MSC does make sense on top of those kind of changes in any case though.

MadLittleMods marked this conversation as resolved.
Show resolved Hide resolved

## 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.msc3991` unstable room version and `org.matrix.msc3991v2`, etc as we develop
and iterate along the way.