MSC2962: Managing power levels via Spaces

[ara4n]

Split out from #1772 to separate concerns (and try to stop Github from crashing): the proposal of how to manage power levels in Matrix based on space membership.

Note that restricting room membership, which used to be part of this MSC, has been split out to #3083.

Rendered

[ara4n]

@MadLittleMods asks "What does mirroring a space mean?". @richvdh, any idea?

[richvdh]

sorry, this wasn't terribly clear. I'm talking about the idea that you want your PLs or memberships in a room to be inherited from a space:

How do I set up a company internal room without being an admin in the company space?

[MadLittleMods]

@richvdh Ahhh, "inherit from a space" makes this line a lot more clear. And your example makes it even more obvious. We should add it to the MSC too ⏩

[ara4n]

@Sorunome commented:

Again, we might want to flesh out #2812 more, as, well, "access to a room" is a permission and we are re-implementing role-based permissions here by creating a bunch of empty rooms

[Sorunome]

Soru posted a lengthy comment over here on why she thinks permission roles are the way to go

[ara4n]

@joepie91 commented:

The more I think about it, the more I feel that this - with some improvements - is a much better solution than the current proposal. It makes a lot of sense for powerlevel changes in rooms to be made by the person who actually made them in the space, much more sense than an anonymous bot user with ambient authority, IMO. It's also much easier to reason about.

It would also remove the need for spaces-as-roles from a powerlevels perspective (hopefully this can be eliminated for join rules in some way as well!), and make all the hard questions regarding whose homeserver is authorative for the bot user, completely obsolete.

Those authority questions in particular are not ones where I expect anyone to have a good answer any time soon, because - as I believe someone else pointed out in another thread - we will effectively just be reinventing a second layer of stateres there. I don't think that is desirable, especially considering the expressed desire to avoid changing the stateres algorithm due to its fragility.

An additional benefit of this approach, is that there is a semantically obvious way to copy over default powerlevel requirements too, not just user-powerlevel assignments. This doesn't seem to be part of the PL sync proposal yet, but IMO should be.

In terms of API design, a 'synchronized powerlevel change' can be expressed either as a regular powerlevel change on the space, or as a special operation / event type. I don't yet have a strong preference for either, and would be interested in arguments for/against either.

The situation of "cannot synchronize PLs to rooms that the person does not have access in" is IMO sufficiently handled by simply making it an error condition to apply synced PL changes to a space without having the necessary access in all child rooms, with an optional "then just do it for the rooms where it's possible" flag. This allows for eg. a "you do not have permission to update all rooms, do you want to continue anyway?" UI.

That having been said, once the PLs have been manually synchronized across rooms once, by each room's admins, it should from that point on be self-sustaining; any space-wide PL change that allows a new admin to change PLs, will also grant that new admin those permissions for rooms. Therefore, "cannot change in all rooms" should be a rare occurrence.

This also addresses the "what if someone is using it for a personal room collection" usecase, as in those circumstances the user simply won't be able to synchronize PL changes across those rooms unless they have the needed PL within those rooms; in which case they can still choose to do so "where possible", following the aforementioned UI.

To address the main objections here:

The problem of Bob not wanting to be a member of all such rooms, is pretty easy to to address: simply make "being a member of a room" not a prerequisite for setting powerlevels in a room at all. This requires a new room version, but only requires a change in authorization rules, not in the stateres algorithm, which makes it a low-risk change.

Likewise, since powerlevel and other permission changes are already gated by powerlevel restrictions anyway, and so would normally not be creatable by someone who doesn't have some sort of prior reputation in a room, permitting permission change events from non-joined users would be a safe change.

I'm thinking specifically of making the following change in the authorization rules, changing:

If the sender's current membership state is not join, reject.

... to:

If the sender's current membership is join, allow. If the sender's current membership is leave or invite, and type is m.room.power_levels, allow. Otherwise, reject.

(Further permission change events, like m.room.history_visibility, may also be worth rolling into this if synchronizing those is desirable too.)

The problem of Bob generating PLs every time someone comes and goes from the space... is this really a problem? Wouldn't the set of members with any non-default powerlevels at all normally be pretty limited, with those powerlevels being normally assigned?

It does not seem necessary to me to specify powerlevels for every user which did not explicitly receive a special one, and I don't think a user needs to be present in a room to receive a powerlevel assignment (at the time it is actually made on a space-wide level)? So there should be no need to change any powerlevels upon join/leave at all.

The problem of people not being able to mirror a space - is that really true? As far as I can tell, that's precisely what this approach would allow for, and with sensible PL propagation semantics too.

[ara4n]

@deepbluev7 commented:

This basically implements role based permissions via group membership. This means you will needs separate spaces to define different groups of users instead of being able to define permissions inside the group, by assigning everyone a role/powerlevel. I would prefer it, if I could assign who is admin or not on the space level and inherit that to all children. I don't think I see that listed in alternatives?

@Sorunome commented:

Sadly it are only fake role-based permissions, as it still underlyingly maps to PLs.

Perhaps it makes sense to look more closely at #2812 before continuing here much?

[ara4n]

@deepbluev7 commented:

While so far this hasn't been an issue, I think with spaces you will run into event size limits here. Just adding a community with 10 000 members to the mapping will add 10 000 userids here. Quoting the spec:

The complete event MUST NOT be larger than 65535 bytes

So if each user has a 4 char mxid, this will put us over the limit. I think spaces should scale to 100 000 users.

@joepie91 commented:

Couldn't we simply introduce a new state event type, m.auto_power_level or so, with the mxid being the statekey and the content being the default power level?

@Sorunome commented:

How about leave out users (and auto_users) from the m.room.power_level state event, and then set an m.room.power_level with the state key the mxid and the content

{
  "user": 100,
  "auto_user": 50
}

That way we make sure that we completely decouple the infinitly-growing object structure and thus truly allow rooms of unlimited sizes. This would obviously require a new room version and clients would start to have to do stuff depending on room version (promoting / demoting users)

I commented:

ooh, i like that.

[richvdh]

yeah, I like it too. It's orthogonal to spaces though.

[ara4n]

@t3chguy commented on 26 Nov 2020

So given that the admin bot is operated by the homeserver of the space-room admin which added the room to the space-room, wouldn't that mean massive inconsistency if the admin-ship of the space-room is spread amongst multiple servers and if one of those servers went down then partial/total permissions sync breakage with no proposed recovery?

@erdnaxeli commented on 26 Nov 2020

I think the admin bot is operated by the room which created the room, as it is said a few lines up.

@t3chguy commented on 26 Nov 2020

How would that work given

• existing rooms can be added to Spaces, those rooms may originate from servers which no longer exist
• the server which creates the room can still cease to exist and thus that room now being broken

@erdnaxeli commented on 26 Nov 2020

Good questions, I have no idea :D

No matter where the bot is heberged, it could go down. I think we need a way for room's admin to setup a new one. This is actually just inviting the bot and giving it a power level 100. You could invite the one on your HS (assuming you trust your own HS).

Maybe this whole HS's admin bot should be specified alongside this one.

@richvdh commented on 26 Nov 2020

as @erdnaxeli says, the admin bot is part of the HS of the room creator.

and yes, if that server goes away, we have a problem. The solution probably amounts to having more than one admin bot in the room, which in turn means having good answers to "how do they decide which one should actually do the work". Whether the extra bots get automatically added whenever a user on another server is granted PL100, or requiring an explicit operation as @erdnaxeli suggests, is open to debate.

(I also think, though it's not written here, that the idea was that if the room creator left the room, so would the admin bot, to avoid accumulating rooms on the server where there are no real users.)

@ashkitten commented on 26 Nov 2020

it seems to me that there is no good way to actually synchronize the permissions and room state across multiple rooms, but maybe we should rethink if that's actually necessary. would it work to simply introduce inheritance so that when looking up permissions and power levels it would defer to the parent room (with the ability to override that per child room)?

@richvdh commented on 27 Nov 2020

@ashkitten I'm not quite sure what you're suggesting, but it sounds a bit like the dismissed idea at https://github.com/matrix-org/matrix-doc/pull/1772/files#diff-cdaa2b5bfe73f40db1903d17b1d242d8caa54d4af81e78e0396a369bcd9a1b90R304-R312?

@deepbluev7 commented on 27 Nov 2020

One of the biggest issues with current groups is, that they are bound to a specific server. spaces via rooms was supposed to fix that, at least someone may have said that at some point. Binding the power_level manipulation to a single server again, sounds like a step in the wrong direction. When you add multiple bots on multiple servers, you then run into the issue, that you need to do conflict resolution. Which means you are basically implementing state res a level above normal state res. I think it would be much more natural to extend state res to work across multiple rooms instead in a few specific cases. Yes, that is complicated, but it gives you a lot more tools to work with and can be useful for community only join rules as well. Otherwise you don't really need the bot user, you could just as well implement all of this clientside without reserving special IDs (well, for the most part, admins would need to join all rooms).

@richvdh commented on 27 Nov 2020

I think it would be much more natural to extend state res to work across multiple rooms instead in a few specific cases.

natural maybe, but would absolutely annihilate our chances of landing this feature within the next year. Seriously, I'm pretty sure getting state-res working across rooms would be an entire PhD thesis in its own right.

If people want to take on that research, I would be very interested to read the outcome. Meanwhile, I'm not prepared to block Spaces on a feature that would take months of research. We need to work with the tools we have available today and that absolutely excludes cross-room state-res/event-auth. This is simply not up for debate.

In any case, this suggestion is off-topic for this comment thread, which is about "where does the bot run", not "how can we completely change the proposal so you don't need a bot".

@InfiniteWorldSoftware commented:

So given that the admin bot is operated by the homeserver of the space-room admin which added the room to the space-room, wouldn't that mean massive inconsistency if the admin-ship of the space-room is spread amongst multiple servers and if one of those servers went down then partial/total permissions sync breakage with no proposed recovery?

Probably, unless the bot would exist on all participating servers. The problem then would be: what happens if the bots disagree?

If the bots don't exist on all participating homeservers, MSC1772 is really nothing more than a more complex /r0/groups in the spec.

@ara4n commented:

the bot is just used to keep PLs updated based on group memberships (which is a separate feature to the core spaces proposal anyway, and should be split out into a separate MSC - we only wrote it in one place to ensure it was considered when doing the core MSC). To say that MSC1772 is "just /groups" if the PL-management bot sits on a single server is completely wrong (/groups doesn't even have PL management).

When you add multiple bots on multiple servers, you then run into the issue, that you need to do conflict resolution. Which means you are basically implementing state res a level above normal state res.

Yes, if you end up with multiple servers doing PL-management, you need some way of conflict resolution. However, this could be as simple as a social mechanism: if the admins of a room decide they want @:matrix.org rather than @:example.com to expand out the PLs, then they could make give the right bot power to do so. This feels like a perfectly practical pragmatic solution that avoids us being sucked into the complexity of cross-room state res.

@deepbluev7 commented

However, this could be as simple as a social mechanism: if the admins of a room decide they want @:matrix.org rather than @:example.com to expand out the PLs, then they could make give the right bot power to do so. This feels like a perfectly practical pragmatic solution that avoids us being sucked into the complexity of cross-room state res.

I guess that is a good point. In theory, as long as an admin on server B still exists and they have admin capabilities in all rooms, they should be able to change the group bot in all rooms, even if server A goes down. It does have the annoying side-effects of permission managements across rooms being broken until you notice A is down and I'm not really fond of that. At the small server scale servers often go down and there is not really one reliable server you can trust, unless you add one of the bigger ones. Those cases are at least recoverable though, while multiple bots have a few unrecoverable edge cases. For the first iteration that is probably completely fine and if it turns out to be an issue, since it doesn't need a lot of invasive changes to implement, it should be replaceable with a better solution, if someone can come up with one.

[ara4n]

@grinapo commented on 17 Nov 2020

I have read the above and dismissed ideas but I am not sure whether the following was in:

The space has an automatically existing user, like @_space_whatever:example.com, which joins all member rooms (unless forbidden).
The specific room admins may or may not assign an elevated power level to this user. (This may be a part of the room joining the space, or acknowledging it.) (It is advised not to give space_user a level equal to the room creator/highest level user.)

This space_user would act on space defined states, like

• if the space defines a room as user_level_inheriting, then tries to set space userlevel for a user in the room, too.
• if ban_inheriting, .... same.
  And same for whatever event we have.

Space admins who have power to set events in the space room may do that, and space_user would reflect these in rooms it has the power to (and possibly the room member events in the space room define as).

If a room admin disagrees with the space admin s/he kickbans the space user.

This machanism may let all and any events reflected in the member rooms without the need to tell now what these events may be in the future.

@richvdh commented on 20 Nov 2020 Member

we did consider a pseudo-user-per-space, but it felt a bit redundant. What would be the advantage over having a single pseudo-user which can work on all spaces?

Beyond the userid, I'm not clear how your suggestion differs from our existing proposal?

@grinapo commented on 23 Nov 2020

we did consider a pseudo-user-per-space, but it felt a bit redundant. What would be the advantage over having a single pseudo-user which can work on all spaces?

Why a "normal" [looking] user?
Handled as a normal user: have to join the room to be there, have to possess levels to do actions, can be kicked or banned. This machanism is already in place and requires no additional spec.

Why multiple users?
Since a room can be a part of multiple spaces (as far as I understand) there would be no way to allow SpaceX but reject SpaceY in a specific room to make actions when the room is included in both.

Beyond the userid, I'm not clear how your suggestion differs from our existing proposal?

It was not clear to me how the proposal handles the possible differences (or power split) between space admin(s) and room admin(s).
Also I'd kind of prefer not to create more spec than necessary, and reuse already existing functions. If the proposal just does that then I was mistaken and superfluous.

@ara4n commented

per-space bots (or puppeting a real admin user for the space) is certainly interesting to just make the problem of "who is tweaking the PLs"? a purely social admin one - especially if you have multiple admins trying to compete for control of the same room, as per grin's example.

[Sorunome]

What about access control the other way (maybe need in work arose for that, not entirely sure yet if our issue would be solved by this):

If you are in a room, you are allowed to enter its space, however, if you are in a space, you are not necessarily allowed to enter its room

[thoraj]

We're really excited about the re-imagined spaces work, and look forward to testing it out

Matrix would benefit greatly from a proper role based access control system. But in lieu of that we are planning to use a ThirdPartyRules plugin to take control over power levels and "virtual" users (user not in the room, but which are in the power level users list.

So we're hope that whichever design you settle for will play nice with the ThirdPartyRule model.

[erkinalp]

This is the alternative I support the most.

[erkinalp]

Reject as this affects the server-side authorisation checks

Suggested change

	If `mappings` is not a list, the whole event is ignored. Any entries in the list
	which do not match the expected format are ignored.
	If `mappings` is not a list, the whole event is ill-formed. Any entries in the list
	which do not match the expected format are ill-formed.

[joepie91]

FYI, I've submitted a competing (and IMO much simpler) MSC: #3216

(Not posting as a review comment because it's not a resolvable issue, and discussion about it should happen over on that MSC anyway)

[turt2live]

nit: s/space/room to inherit some of the generic behaviour of restricted rooms. Ie: it seems perfect valid to say that #CompanyAnnouncements is synchronized with #CompanyExecutives without a need for a space between them.

[clokep]

Are these aliases or IDs? I would recommend using room_id to match MSC3083 too. 👍

[turt2live]

Not sure what the exact intention was, but with Extensible Events and such on the horizon, feels like we can denote these by feature name rather than schema.

Suggested change

	`m.room.message` messages of type `m.msgtype`.
	notice messages.