-
Notifications
You must be signed in to change notification settings - Fork 385
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
base: main
Are you sure you want to change the base?
Conversation
> 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. |
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.
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 🙏
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. |
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.
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).
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.
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?
(leaving the room is not the same as removing power levels though)
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
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 |
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'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.
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.
"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.
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.
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.
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:
Other related references: