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

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

Conversation

MadLittleMods
Copy link
Contributor

@MadLittleMods MadLittleMods commented Apr 4, 2023

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

Adding the ability to raise your power level (alongside everyone else) above the current value in existing rooms.


Rendered

Server implementations:

  • Implementations needed

Other related references:

@MadLittleMods MadLittleMods changed the title MSCXXXX: Power level up! Taking the room to new heights MSC3991: Power level up! Taking the room to new heights Apr 4, 2023
> 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

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 🙏

@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:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Apr 5, 2023
Comment on lines +60 to +62
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.
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

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)

@MadLittleMods MadLittleMods marked this pull request as ready for review April 5, 2023 22:29
@MadLittleMods

This comment was marked as off-topic.

@progval

This comment was marked as off-topic.

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
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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:maintenance MSC which clarifies/updates existing spec 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

6 participants