From e746aa3aad2a0f92ea2a6468f74510f573f6b9de Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Fri, 30 Oct 2020 11:16:32 +0000 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Matthew Hodgson --- proposals/1772-groups-as-rooms.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/1772-groups-as-rooms.md b/proposals/1772-groups-as-rooms.md index 18b9addb..56d4e505 100644 --- a/proposals/1772-groups-as-rooms.md +++ b/proposals/1772-groups-as-rooms.md @@ -105,7 +105,7 @@ upgrades would need considering. XXX Rooms also need to be able to advertise related spaces, so that users can discover other, related, rooms. -XXX We also want to be have "secret" rooms within a heirarchy: do this with +XXX We also want to be have "secret" rooms within a hierarchy: do this with either a "parent" state in the child, or possibly by hashing the room id? Space-rooms may have `m.room.name` and `m.room.topic` state events in the same @@ -228,7 +228,7 @@ mechanics of propagating changes into real `m.room.power_levels` events. Several options: - * Push-based: + * Push-based options: * 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 @@ -263,7 +263,7 @@ Several options: space, without having any particular control in that group. (XXX: Is that actually a useful feature, at least as far as PLs are concerned?) - Problem: What do you do if the admin who sets ip the PL relationship + Problem: What do you do if the admin who sets up the PL relationship disappears? Again, either the humans have to step in and create a new admin, or maybe we can have multiple admins with random backoff?