add an issue about lost parent links
@@ -153,9 +153,11 @@ relationship can be expressed in one of two ways:
space that it should not be, clients could ignore such `m.space.parent`
events unless either (a) there is a corresponding `m.space.child` event in
the claimed parent, or (b) the sender of the `m.space.child` event has a
- sufficient power-level to send such an `m.space.child` event in the parent.
- [Checking the power-level rather than requiring an *actual* `m.space.child`
- event in the parent allows for "secret" rooms (see below).]
+ sufficient power-level to send such an `m.space.child` event in the
+ parent. (It is not necessarily required that that user currently be a
+ member of the parent room - only the `m.room.power_levels` event is
+ inspected.) [Checking the power-level rather than requiring an *actual*
+ `m.space.child` event in the parent allows for "secret" rooms (see below).]
Where the parent space also claims a parent, clients can recursively peek
into the grandparent space, and so on.
@@ -292,6 +294,13 @@ None at present.
different querying users. (It may be possible to simulate this behaviour
using smaller spaces).
+* The requirement that `m.room.parent` links be ignored unless the sender has a
+ high PL in the parent room could lead to suprising effects where a parent
+ link suddenly ceases to take effect because a user loses their PL in the
+ parent room. This is mitigated in the general case by honouring the parent
+ link when there is a corresponding `m.room.child` event, however it remains
+ a problem for "secret" rooms.
+
## Rejected alternatives
### Use a separate state event for type of room
