Skip to content

MSC3915: Owner power level #3915

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

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

MSC3915: Owner power level #3915

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a38ebc2
MSC3915: Owner power level
ara4n Oct 23, 2022
5bec5cf
typo
ara4n Oct 23, 2022
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
71 changes: 71 additions & 0 deletions proposals/3915-owner-power-level.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
# MSC3915: Owner power level
Copy link
Contributor

@FSG-Cat FSG-Cat Dec 11, 2022

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.

Copy link

@EmilJeppsson EmilJeppsson Dec 11, 2022 •
edited
Loading

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.


## Problem

Matrix today does not distinguish between 'room admins' who have permission to do privileged operations in a room
(set PLs, ACLs, tombstones, history visibility, encryption, create/remove moderators)... and the 'owners' aka 'founders'
of a room, who have overall responsibility and ownership for it and appoint (and deappoint) admins to help them run it.

As a result, it's common for a room founder to promote a set of users to be admins at PL100 to share responsibility
for administering the room... 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).

This is particularly problematic for users migrating from other communities such as Discord or even IRC where room
permissions distinguish owner from admin, and so apply the same terminology in Matrix, accidentally promoting users to
admin thinking they can revoke it (despite the UI warnings to the contrary).

Finally, the current workaround of having to manually assign 'admins' to PL99 and manually rewrite the PL event
thresholds is incredibly uninuitive and bad UI (for instance, many clients will show the PL99 as 'Moderator' in the UI,
confusing it with PL50). Moreover, you can't apply the workaround in retrospect; the owner either has to create a
whole new room with the correct permissions or anticipate the problem before you accidentally assign a user to PL100.

This closes the embarassingly long-standing https://github.com/matrix-org/matrix-spec/issues/165 spec issue, and
replaces the previous flawed [MSC3510](https://github.com/matrix-org/matrix-spec-proposals/pull/3510) proposal.

## Proposal

* We expand the recommended range of PLs to 0-150, with 150 described as 'Owner'.
* The room creator defaults to PL150.
Copy link
Member

@richvdh richvdh Oct 23, 2022

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.

Copy link
Contributor

@ShadowJonathan ShadowJonathan Oct 24, 2022 •
edited
Loading

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.

* 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.
Comment on lines +27 to +30
Copy link
Member

@richvdh richvdh Oct 23, 2022

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?

Copy link
Member Author

@ara4n ara4n Oct 26, 2022

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.


Copy link
Contributor

@Mikaela Mikaela Oct 23, 2022 •
edited
Loading

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.

Copy link
Member Author

@ara4n ara4n Oct 26, 2022

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.

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

@BLumia BLumia Apr 22, 2023 •
edited
Loading

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)

Copy link

@su-ex su-ex Apr 22, 2023

Choose a reason for hiding this comment

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

I strongly disagree:

  1. Sharing ownership is a common concept, see MSC3510: Let users kick/ban/demote each other #3510 (comment).
  2. There are already rooms that go beyond that scope.
  3. That just adds complexity.
  4. 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.

Copy link

@BLumia BLumia Apr 22, 2023 •
edited
Loading

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)

Copy link

@BLumia BLumia Apr 22, 2023

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:

  1. Transfer the ownership to someone else.
  2. Demoting themself to PL<=100

And for client developers, we should warn the user about performing this action in both cases.

Copy link

@su-ex su-ex Apr 22, 2023

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

Copy link
Contributor

@FSG-Cat FSG-Cat Apr 24, 2023

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.

Copy link

@BLumia BLumia Apr 25, 2023

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:

  1. Add an option to use PL101 when creating a room.
  2. Keep all the permission parts the same as before (stick to 0~100 range).
  3. 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.

Copy link

@su-ex su-ex Apr 25, 2023 •
edited
Loading

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)

Copy link

@BLumia BLumia Apr 25, 2023

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

Copy link

@morguldir morguldir Sep 23, 2024

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

bump, and lets clients implement cmopletely different UI for appointing/deappointing admins to the special-case of
transferring/sharing ownership.

## Potential issues

None?
Copy link
Contributor

@Mikaela Mikaela Oct 23, 2022

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.

Copy link
Contributor

@Mikaela Mikaela Oct 23, 2022

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?

Copy link
Member

@dbkr dbkr Oct 25, 2022

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.

Copy link
Member Author

@ara4n ara4n Oct 26, 2022

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.

Copy link
Member

@richvdh richvdh Oct 27, 2022

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.

Copy link
Contributor

@Mikaela Mikaela Oct 27, 2022

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.

Copy link

@jackmawer jackmawer Nov 14, 2022

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.


## Alternatives

* We could add an `owner` field or `owners` field to the PL event. However, this breaks compatibility, and has no
obvious benefit from simply having a higher PL number for owners.

* We could redeclare the Admin PL threshold to be 75 or 99 or similar, thus showing all existing Admins as being Owners
in the UI. However, this will cause confusion with older clients, as well as confusion over users being seen to
apparently suddenly changing power levels. It's better to reflect the current reality: that historically we haven't
had the concept of owners, rather that retconning the historical admins into being owners.

* We could workaround it with an 'adminbot' with PL100, which is the sole robot owner of the room, and ensures that
human admins don't accidentally promote each other. This is a horrible hack, given the protocol itself should
intrinsically support basic features such as access control.

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

## Security considerations

Clients or servers which incorrectly assume that PLs range from 0 to 100 may get confused. This would clearly be
an implementation bug however.

## Unstable prefix

None

## Dependencies

None
Copy link
Member

@dbkr dbkr Oct 25, 2022

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.

Copy link
Member Author

@ara4n ara4n Oct 26, 2022

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

Copy link

@Ai-rin Ai-rin Nov 13, 2022

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 ?

Copy link
Contributor

@FSG-Cat FSG-Cat Nov 13, 2022

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.