Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-01-07 16:33:43 +01:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

switch to allowing multiple parents

Browse source 
to accomodate @Sorunome's use cases for secret rooms to exist in multiple spaces.
also remote , as we always have  now we use room ids
This commit is contained in:
Matthew Hodgson 2021-01-14 02:02:27 +00:00
parent 97103c44cd
commit 91fe7a79b6
1 changed files with 21 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
proposals/1772-groups-as-rooms.md
View file

@ -81,16 +81,14 @@ relationship can be expressed in one of two ways:
1. The admins of a space can advertise rooms and subspaces for their space by
setting `m.space.child` state events. The `state_key` is the ID of a child
room or space, and the content should contain a `via` key which gives a list
of candidate servers that can be used to join the room. `present: true` key
is included to distinguish from a deleted state event. Something like:
of candidate servers that can be used to join the room. Something like:
```js
{
"type": "m.space.child",
"state_key": "!abcd:example.com",
"content": {
"via": ["example.com", "test.org"],
"present": true
"via": ["example.com", "test.org"]
}
}
@ -99,7 +97,6 @@ relationship can be expressed in one of two ways:
"state_key": "!efgh:example.com",
"content": {
"via": ["example.com"],
"present": true,
"order": "abcd",
"auto_join": true
}
@ -113,7 +110,7 @@ relationship can be expressed in one of two ways:
}
```
Children where `present` is not present or is not set to `true` are ignored.
Children where `via` is not present are ignored.
The `order` key is a string which is used to provide a default ordering of
siblings in the room list. (Rooms are sorted based on a lexicographic
@ -126,23 +123,31 @@ relationship can be expressed in one of two ways:
automatically joined by members of the space: see
[below](#auto-joined-children).
2. Separately, rooms can claim a parent via the `m.space.parent` state
event:
2. Separately, rooms can claim parents via the `m.space.parent` state
event.
Similar to `m.space.child`, the `state_key` is the ID of the parent space,
and the content should contain a `via` key which gives a list of candidate
servers that can be used to join the parent.
```js
{
"type": "m.space.parent",
"state_key": "",
"state_key": "!space:example.com",
"content": {
"room_id": "!space:example.com",
"via": ["example.com"]
"via": ["example.com"],
"present": true,
"canonical": true,
}
}
```
In this case, after a user joins such a room, the client could optionally
start peeking into the parent space, enabling it to find other rooms in
that space and group them together.
Parents where `via` is not present are ignored.
`canonical` determines whether this is the main parent for the space. When
a user joins a room with a canonical parent, clients may switch to view
the room in the context of that parent space, peeking into it in order to
find other rooms and group them together.
To avoid abuse where a room admin falsely claims that a room is part of a
space that it should not be, clients could ignore such `m.space.parent`
@ -154,12 +159,9 @@ relationship can be expressed in one of two ways:
Where the parent space also claims a parent, clients can recursively peek
into the grandparent space, and so on.
Note that each room can only declare a single parent. This could be
extended in future to declare additional parents, but more investigation
into appropriate semantics is needed.
This structure means that rooms can end up appearing multiple times in the
room list hierarchy, given they can be children of multiple different spaces.
room list hierarchy, given they can be children of multiple different spaces
(or have multiple parents in different spaces).
In a typical hierarchy, we expect *both* parent->child and child->parent
relationships to exist, so that the space can be discovered from the room, and