diff --git a/proposals/1772-groups-as-rooms.md b/proposals/1772-groups-as-rooms.md index 76520b92e..e7d6eea7d 100644 --- a/proposals/1772-groups-as-rooms.md +++ b/proposals/1772-groups-as-rooms.md @@ -258,6 +258,9 @@ This means that a new `m.room.power_levels` event would be generated whenever the membership of either `!mods` or `!users` changes. If a user is in both spaces, `!mods` takes priority because that is listed first. +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. + #### Implementing the mapping When a new room is created, the server implicitly adds a "room admin bot" to @@ -284,6 +287,139 @@ access to it is itself restricted via `power_levels`. This could be enforced by the admin bot so that no `m.room.power_levels` events are generated unless `power_level_mappings` is appropriately restricted. +Some sort of rate-limiting may be required to handle the case where the mapped +space has a high rate of membership churn. + +#### Alternatives + +Things that were considered and dismissed: + +* Rather than defining the mapping in the room, define a template power-levels + event in a parent space, which will be inherited by all child rooms. For example: + + ```js + { + "type": "m.space.child_power_levels", + "state_key": "", + "content": { + // content as per regular power_levels event + } + } + ``` + + Problem 1: No automated mapping from space membership to user list, so the + user list would have to be maintained manually. On the other hand, this + could be fine in some situations, where we're just using the space to group + together rooms, rather than as a user list. + + Problem 2: No scope for nuance, where different rooms have slightly + different PLs. + + Problem 3: what happens to rooms where several spaces claim it as a child? + They end up fighting? + + Problem 4: Doesn't allow for random room admins to delegate their PLs to a + space without being admins in that space. + +* To implemplement the mapping, we require any user who is an admin in the + space (ie, anyone who has permission to change the access rights in the + space) to also be admins and members of any child rooms. + + Say Bob is an admin in #doglovers and makes a change that should be + propagated to all children of that space. His server is then responsible + for generating a power-levels event on his behalf for each room. + + Problem 1: Bob may not want to be a member of all such rooms. + + Problem 2: It will feel odd that Bob's user is seen to be generating PL + events every time someone comes and goes from the space. + + Problem 3: It doesn't allow users to set up their own rooms to mirror a + space, without having any particular control in that space (though it is + questionable if that is actually a useful feature, at least as far as PLs are + concerned.) + +* Another alternative for implementing the mapping: the user that created the + relationship event (or rather, their homeserver, using the user's ID) is + responsible for copying access controls into the room. + + Problem 1: What do you do if the admin who sets up the PL relationship + disappears? The humans have to step in and create a new admin? + + Problem 2: Again it seems odd that these PL changes come from a single user. + +* Is it possible to implement the mappings from multiple users, some of which + may not have PL 100? After all it's possible to set rooms up so that you can + change PL events without having PL 100. + + It gets horribly messy very quickly, where some admin users can make some + changes. So some get supressed and then get made later anyway by a different + admin user? + +* Is it possble to apply finer-grained control to the + `m.room.power_level_mappings` event than "you must be max(PL)"? Applying + restrictions post-hoc (ie, having the admin bot ignore settings which were + set by underpriviledged users) is an absolute minefield. It might be possible + to apply restrictions at the point that the event is set, but it sounds + fiddly and it's not clear there is a real use-case. + +* This solution smells a bit funny because of the expansions (causing all the + redundant mxids everywhere as the groups constantly get expanded every time + something happens). + + * Could we could put a hash of the space membership in the PL instead of + expanding the wole list, so that servers have a way to check if they are + applying the same list as everyone else? + + Feels like it will have bad failure modes: what is a server supposed to do + when the hash doesn't match? + + * Could version the space memberships, so you can compare with the source of + the space membership data? + + * PL events just record the delta from the previous one? (So a new server + would need to get all the PLs ever, but… is that a bad thing?) ... maybe + + These optimisations can all be punted down the road to a later room version. + +* Other ways of handling the merge of automatic and manual PL settings: + + * Add hints to the automated mapper so that it can maintain manually-assigned + PLs. This could either be another field in `power_levels` which plays no + part in event auth: + + ```js + { + "type": "m.room.power_levels", + "content": { + "users": { + "@roomadmin:example.com": 100, + "@spaceuser1:example.org": 50 + }, + "manual_users": { + "@roomadmin:example.com": 100 + } + } + } + ``` + + ... or stored in a separate event. Clients would be responsible for updating + both copies of the manually-assigned PLs on change. + + Problem: Requiring clients to make two changes feels fragile. What if they + get it wrong? what if they don't know about the second copy because they + haven't been designed to work in rooms in spaces? + + * Require that even regular PLs go through the automated mapper, by making + them an explicit input to that mapper, for example with entries in the + `m.room.power_level_mappings` event suggested above. + + Problem: Requires clients to distinguish between rooms where there is an + automated mapper, and those where the client should manipulate the PLs + directly. (Maybe that's not so bad? The presence of the `mappings` event + should be enough? But still sucks that there are two ways to do the same + thing, and clients which don't support spaces will get it wrong.) + ### Restricting room membership based on space membership A desirable feature is to give room admins the power to restrict membership of @@ -376,6 +512,24 @@ help. but it's unclear what the desired semantics are: the `allowed_spaces` list and SpaceA is removed. What should happen when the user leaves SpaceB? Are they exempt from the kick? +#### Alternatives + +* Maintain some sort of pre-approved list as the space membership changes in a + similar way to the PL mapping, possibly via a new membership state. + + Could lead to a lot of membership churn, from a centralised control point. + +* Base it on invite-only rooms, and generate invite events on the fly. Kind-of + ok, except that we'd want the invites to be seen as having a sender of a + management bot rather than an arbitrary user, which would mean that all joins + would have to go through that one server (even from servers that were already + participating in the room), which feels a bit grim. We could have multiple + admin bots to mitigate this, but it gets a bit messy. + +* Change the way that `allowed_spaces` and invites interact, so that an invite + does not exempt you from the `allowed_spaces` requirements. This would be + simpler to implement, but probably doesn't match the expected UX. + ## Future extensions The following sections are not blocking parts of this proposal, but are @@ -468,8 +622,8 @@ These dependencies are shared with profiles-as-rooms different querying users. (It may be possible to simulate this behaviour using smaller spaces). -## Unstable prefix +## Unstable prefix The following mapping will be used for identifiers in this MSC during development: