-
Notifications
You must be signed in to change notification settings - Fork 379
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
MSC3915: Owner power level #3915
base: main
Are you sure you want to change the base?
Conversation
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 have a concern on how upgrading current rooms work.
|
||
## Potential issues | ||
|
||
None? |
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.
How will existing rooms upgrade to this considering a room upgrade currently copies power levels from the previous room?
I think this proposal should require the upgrade process to maintain that the upgrader either gets this 150 or gets the new default power level depending on which is higher or otherwise I think Element Web would downgrade the administrator instantly, while I haven't tried this.
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.
Also how about Schalar and the bridges it manages? Willl Schalar/IRC integration start getting power level 150 to perform room takeover from the founder?
How will a bridge like LiberaChat's behave if it doesn't have the power to remove inactive users from the room? Will it silently break?
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.
Valid concerns, but I'd advocate for rolling this out for new rooms first, and then worry later about if & how we upgrade existing rooms. What individual bridge implementations choose to do with it is not for us to decide at a spec 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.
This is a fair point; currently Admins can tombstone rooms, so a malicious admin could currently fake this today by creating a new room where they're the sole admin (or owner) and tombstoning the room into it. I don't think that the act of upgrading a room should make you the owner, but perhaps we should make tombstones and other super-destructive actions (ACLs) owner-only for new rooms, as you propose in the other comment.
Meanwhile, existing ownerless rooms with multiple admins can break the impasse by tombstoning the room to point to a new room with a well-defined 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.
perhaps we should make tombstones and other super-destructive actions (ACLs) owner-only for new rooms
this seems like it would run the risk of ending up with rooms that can't be upgraded because the owner has gone missing. So to avoid that, people start giving rooms multiple owners, and then later they wonder why they can't demote owners, and we're back at square one.
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.
perhaps we should make tombstones and other super-destructive actions (ACLs) owner-only for new rooms
I think this could make moderation tools have even higher threshold for use such as Mjølnir that needs access to manage ACL for server bans. The easiest action seems like making the bot a co-owner (which I understand is supposed to be somewhat hidden action in the UI(?)), which results to it being unmanageable by other owners unless they have access to the bot account in case of trouble.
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.
Meanwhile, existing ownerless rooms with multiple admins can break the impasse by tombstoning the room to point to a new room with a well-defined owner.
would it not make sense to, for example, read the room history and find the first user who created the room, and upgrade that one person to PL150? that would potentially allow an easier transition where owners can then be applied as needed.
* The room creator defaults to PL150. | ||
* We tighten the language in the spec which says "Clients may wish to assign names to particular power levels." to | ||
specify the threshold names more concretely, to avoid divergent implementations. | ||
|
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.
Just to clarify, PL100 will still be able to ACL ban the owner or tombstone the room pointing somewhere they have PL150 and the original owner nothing?
edit: I meant this feedback for line 32, but seem to have mistouched on phone.
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, although as you imply, this was a thinko and should be addressed in this MSC. thanks for picking it up.
This comment was marked as duplicate.
This comment was marked as duplicate.
* We expand the recommended range of PLs to 0-150, with 150 described as 'Owner'. | ||
* The room creator defaults to PL150. | ||
* We tighten the language in the spec which says "Clients may wish to assign names to particular power levels." to | ||
specify the threshold names more concretely, to avoid divergent implementations. |
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.
for clarity, could you link to the parts of the spec you are proposing to change? I think it is just https://spec.matrix.org/v1.4/client-server-api/#permissions, where the current recommended mapping is given, and also a vaguely-worded "the room creator's power level defaults to 100". [1]
We might also want to update https://spec.matrix.org/v1.4/client-server-api/#post_matrixclientv3createroom to recommend explicitly that a PL be sent giving the creator PL150 (currently there is no explicit PL given here).
[1] Does it mean the PL before or after the first PL event, or both?
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, I was thinking of https://spec.matrix.org/v1.4/client-server-api/#permissions and https://spec.matrix.org/v1.4/client-server-api/#post_matrixclientv3createroom.
However, as @Mikaela points out, we might want to explicitly change the default PLs further - to stop admins using server ACLs or tombstones to hijack ownership of a room.
## Proposal | ||
|
||
* We expand the recommended range of PLs to 0-150, with 150 described as 'Owner'. | ||
* The room creator defaults to PL150. |
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 need to be more explicit here. In particular: would we change the default power level if there is no power_levels
event (defined to be 100 at https://spec.matrix.org/v1.4/client-server-api/#mroompower_levels)? I don't think this is strictly necessary (since the first PL event is special-cased), and doing so would require a room version bump, but it would be nice to keep things consistent.
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 also touched upon this in my comment, if this is the intention, this new permissions structure could also be introduced with that new room version.
|
||
## Dependencies | ||
|
||
None |
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.
Have tried to address a few of the comments here. In general, this is a thing I've been slowly convincing myself of independently recently, so I think I agree it's the way to go. It doesn't magically solve all problems, but it gets us to a place where admin of rooms is a bit easier to understand, I think.
One note on what the actual power levels are (ie. 99/100 vs 100/150): if we use the former then existing rooms kind of get these semantics for free (ie. when a client got updated, members who were previously admins would show up as owners and one of them could demote others to admin level). However, having things appear to change when you're not expecting it could be quite scary: 100/150 would keep old rooms just as they are.
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.
members who were previously admins would show up as owners and one of them could demote others to admin level
they wouldn't, though. admins would still not be able to demote each other. (and owners would not be able to demote each other either).
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.
(and owners would not be able to demote each other either).
Then we have dead accounts problem again? Shoudn't we have an exception for PL150 ?
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.
(and owners would not be able to demote each other either).
Then we have dead accounts problem again? Shoudn't we have an exception for PL150 ?
it would introduce the exact problem this MSC addresses when it replaces #3510. Also in all current room versions the PL names are just visual and actually dont matter at all from the prespective of the authorisation rules so how this is solved im not sure.
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 am not sure about moving power level requirements for owners
Just popping in here to say, as a Matrix user: I did not understand that admin was not distinct from owner, and think putting room creators at a higher power level would be good. A semantic distinction between "owner" and "admin" would be helpful too. |
This will lead to even more unmoderated rooms being abandoned by all admins and moderators over time without a possibility for correction. |
The issues of owners going missing could be solved by implementing an inheritance/succession ability for the owner role. The owner would specify an amount of time since their last room interaction after which other admins/members (in order of power level) would be able to initiate a claim on the owner role. The owner also specifies the time from claim initiation to final succession. An example of what this could look like: Jeff (PL150) has specified 30 days as the countdown from his last event until claims are allowed. He has also specified the succession time as 10 days. This way the power levels could also function as a line of succession. Edit: I realise this could be problematic if multiple admins have the same power level. A possible mitigation would be to reserve PL 101 to 149 solely for line of succession and only allow a single account for each of these power levels (and only one owner). |
@@ -0,0 +1,71 @@ | |||
# MSC3915: Owner 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.
The issues of owners going missing could be solved by implementing an inheritance/succession ability for the owner role. The owner would specify an amount of time since their last room interaction after which other admins/members (in order of power level) would be able to initiate a claim on the owner role. The owner also specifies the time from claim initiation to succession.
An example of what this could look like:
Jeff (PL150) has specified 30 days as the countdown from his last event until claims are allowed. He has also specified the succession time as 10 days. On day 33 since Jeff's AWOL, Bob (PL100) initiates a claim on the owner role. Unless Jeff returns or another admin with higher PL either aborts the claim or takes Bob's place as the claimee, Bob succeeds Jeff as the owner by day 43.
This way the power levels could also function as a line of succession.
Edit: I realise this could be problematic if multiple admins have the same power level. A possible mitigation would be to reserve PL 101 to 149 solely for line of succession and only allow a single account for each of these power levels (and only one owner).
Reply to @EmilJeppsson but as a thread.
I think that this is a idea that is quite flawed based on the very simple fact of we dont touch the concept of time as a trusted variable in the DAG. It has to be assumed you can fake the concept of time and since time is not secure well that means we cant use it in this way. I think the precedent for that time and the DAG should not be mixed like that is well established and does not need to be elaborated.
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.
That's fair.
I guess similar functionality could optionally be delegated to a trusted bot/appservice instead (edit: or a data oracle smart contract but I realise people are not super fond of blockchain tech here).
It wouldn't be decentralised the same way (or part of the spec) but could still be a passable solution to the problem of owner abandoned rooms.
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 strongly suggest we keep using the range 0-100
for power levels, and use 101
as a special power level with some additional server-side implementation conditions. See the comment for details.
For summary:
- We should only allow max to 1 (one) owner per room. (No people have PL101 is fine so we keep 100% compatible with earlier versions. Either no owner or only one owner)
- Role permission should stick to the 0~100 range.
- There should be a standalone API to transfer the PL101 "foundership"/ownership.
- We should avoid "generally" extending the original power level range (
101
as a very special case).
Everything else stays the same (e.g. the `trusted_private_chat` prefix would still give invited users Owner too, to | ||
share ownership of the DM with them). | ||
|
||
This clearly differentiates owners from their delegated admins, is compatible with existing rooms without a room version |
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.
Do you mean we allow multiple owners per room? That sounds like a pretty bad idea since it can lead to the very same issue with the current 100-is-admin solution. We probably need to limit it from the spec so we can avoid mis-implementation. Something like:
- A room can only have zero or one owner/founder (for example, for room that upgraded from earlier versions, there will be no owner, and they need to create a new room to make use of the founder feature)
- The owner (PL > 100) cannot be set directly; it can only be transferred from the original owner to the new owner
- The owner cannot leave the room directly (the owner needs to transfer the ownership/permission to someone else before they can leave)
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 strongly disagree:
- Sharing ownership is a common concept, see MSC3510: Let users kick/ban/demote each other #3510 (comment).
- There are already rooms that go beyond that scope.
- That just adds complexity.
- It's no special case, it gives maximum flexibility
- to even step down as single owner after room creation if it suits the concept of the room more.
- own a project together.
- give bridges the possibility to administer rooms without sharing ownership with the bridge.
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 personally think all you want is the "zero owner" use-case, which is basically the current state.
Additionally maybe we can simply let the room creator to choose the room-creator's power level, can be either PL101 (one owner) or PL100 (zero/no owner).
Sharing ownership is a common concept,
I don't get it. Since PL101 only gets the special power to meddle with other people's power level, all other permissions are the same as PL100. Why is this something that needs to be shared? If that's the case, can a PL101 user change another PL101 user's power level down to 100 or less?
IMO even for the huge-skyscraper room use-case, we should still keep the "owner" count max to one, so we can 100% ensure there can always have one people who can tweak other admin's power level, instead of accidently set two or more people to the max power level and then no-one can do anything to this status.
There are already rooms that go beyond that scope.
I know since current spec doesn't forbid that. If we define the PL range clearly in the spec, then it will be a guideline so other client and server implementation will be trying to follow. As we currently only use the range 0~100 and there are still client/server use 101 or 150 for the "Founder" usage.
btw, if we ensure the spec clearly defines the power level range to 0~100, then we can safely use the PL > 100
condition to check if the user is the owner of the server for maximized compatibility.
That just adds complexity.
Yes, I agree, but it's the only way to address the "... but then regret that they have effectively relinquished ownership of the room, given there is no way to revoke admin permissions (short of coercing the other admins to demote themselves)" issue.
it gives maximum flexibility...to even step down as single owner after room creation if it suits the concept of the room more.
I've mentioned we can transfer the ownership to someone else.
..own a project together.
Then consider PL100 is enough and never set a PL101 user from the beginning of the time. (the zero owner use-case)
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.
And to explain more about my suggestion:
We should only allow max to 1 (one) owner per room.
To be clear, I mean, the room creator can choose to have the PL101 special power (suggested to be the default value) or PL100 when creating a room. As a "Do you want to ensure this room will always have one 'owner' level user?" option. If people intended to share the same permission equally, just choose the PL100 from the beginning of the time.
The owner cannot leave the room directly (the owner needs to transfer the ownership/permission to someone else before they can leave)
Two options:
- Transfer the ownership to someone else.
- Demoting themself to PL<=100
And for client developers, we should warn the user about performing this action in both cases.
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 personally think all you want is the "zero owner" use-case, which is basically the current state.
This is exactly not what I want. I want a clear distinction between owning something and administering something, e.g. bots or bridges should be able to administer the room without taking co-ownership (which is still legitimate to share, but only by intention).
If that's the case, can a PL101 user change another PL101 user's power level down to 100 or less?
Hell no, this was the whole point of #3510 (comment).
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 should probably note. The true range is -2^53+1, 2^53-1. Its just that the default templates dont expose PL values above 100 currently or 150 under this proposal.
Yes, and I mean we should probably stick to using 0~100 when possible, and don't encourage the usage outside that range unless necessary.
Ok so the problem is that going above 100 is well essentially a custom at this point. Rooms all over the place do it and we have a whole client that creates all rooms with custom PL of 101 and can in theory as far as i understand go to any arbitrary number that is legal and that client is Cinny. Like we are well beyond the point of special casing specific PLs and should just go with a proposal like #3949 instead of this proposal.
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 important thing is the word "accidentally".
Yes, and actually when I introduce Matrix to my workmates, almost all of them (who need to be the owner of a room) fall into this pit without realizing the problem. I also got into this pit the first time I used Matrix!
So quoted from this MSC:
- We could ignore it, and try to educate admins into understanding that admin = owner, and they should set custom PLs
if they want something else. In practice this simply hasn't worked, hence this MSC.
In practice this simply hasn't worked.
My suggestion is just simply trying to avoid that from happening by introducing one and only PL>100 special case and all other places stay the same.
we have a whole client that creates all rooms with custom PL of 101 and can in theory as far as i understand go to any arbitrary number that is legal and that client is Cinny
In fact, I think Cinny's current implementation is the most ideal way to do this as long as the user selects the "Founder" role when creating a new room. To assign another user's PL, the drop down keeps in the range 0, 50 and 100. They need to manually enter 101 to get a mistake but users won't do that unless they know what it means. The same applies to the Permission tab since all dropdowns have 0, 50 and 100 as default so 101 won't get used without explicitly entering the value.
And we can amend my suggestion as well. It's okay to allow multiple owners (and currently already possible) but all I mean is introduce a way to reduce the possibility that first-time users falling into the pit. The "stick to range 0~100" is one of the ways to do that. It's okay if the client could still explicitly assign a value but we should document the suggested range to let the client developers so they will know what should avoid to be implemented.
Since most clients follows the 0~100 default PL range thing, adding PL101 (or 150, or 999, or whatever the PL number is. Let's assume we use 101 for now) could be the simplest approach to do so, client developers who want to adapt this spec only needs to do:
- Add an option to use PL101 when creating a room.
- Keep all the permission parts the same as before (stick to 0~100 range).
- Ensure there will be a special warning dialog when user trying to assign PL101 to another user.
If we do this, the server side won't need to do anything, and we only need to document this suggested limitation in the spec so developers could treat this as a sort of thing as an agreement to follow.
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.
It seems were not that far apart, all you want different is
- have 101 instead of 150 (this is indeed arbitrary, but having something "in between to 100" means additional flexibility for use cases we can't foresee right now)
- have clients mandatorily stick to 0~100 in the UI (if clients want to hide the owner level and show a warning or only show a warning or show an info and a warning etc. should be up to the client imo, the only important thing is that certain values are specced out so they mean the same and are named the same across clients)
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 is indeed arbitrary, but having something "in between to 100" means additional flexibility for use cases we can't foresee right now)
Agree! 101, 150 or 999 or any other values are okay for me (I choose 101 just because it's weird enough so other people won't think it's a regular PL value that should be applied elsewhere, but go with 150 is also okay), as long as...
have clients mandatorily stick to 0~100 in the UI (if clients want to hide the owner level and show a warning or only show a warning or show an info and a warning etc. should be up to the client imo, the only important thing is that certain values are specced out so they mean the same and are named the same across clients)
Yeah that's my main suggestion :)
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 like 150 since it gives more flexibility, e.g. if i want to remove the ability for anyone to send reactions, i can set the reaction power level to 150, set everything else at 150 to 149, and demote myself to 149,
Then later i also want to make sure that i don't accidentally enable encryption, so i do the same dance to 148.
And then I accidentally hit the call button in a room with 1000 users, a room which is probably too big for calling either way, so i do the same thing again and demote myself to 147
Define 'owner' as PL150, to clearly differentiate between owners (aka founders), who 'own' a room, versus the room admins they delegate responsibility to for administering the rooms. Stops constant disasters where (despite the warnings) admins give PL100 to other users assuming that Matrix has owner/founder semantics like Discord or ChanServ, when it doesn't.
Fixes matrix-org/matrix-spec#165, and replaces MSC #3510.
Credit to @su-ex for the proto-proposal at #3510 (comment)
Rendered