mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-04-14 07:04:09 +02:00
switch to allowing multiple parents
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:
parent
97103c44cd
commit
91fe7a79b6
|
|
@ -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
|
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
|
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
|
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
|
of candidate servers that can be used to join the room. Something like:
|
||||||
is included to distinguish from a deleted state event. Something like:
|
|
||||||
|
|
||||||
```js
|
```js
|
||||||
{
|
{
|
||||||
"type": "m.space.child",
|
"type": "m.space.child",
|
||||||
"state_key": "!abcd:example.com",
|
"state_key": "!abcd:example.com",
|
||||||
"content": {
|
"content": {
|
||||||
"via": ["example.com", "test.org"],
|
"via": ["example.com", "test.org"]
|
||||||
"present": true
|
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -99,7 +97,6 @@ relationship can be expressed in one of two ways:
|
||||||
"state_key": "!efgh:example.com",
|
"state_key": "!efgh:example.com",
|
||||||
"content": {
|
"content": {
|
||||||
"via": ["example.com"],
|
"via": ["example.com"],
|
||||||
"present": true,
|
|
||||||
"order": "abcd",
|
"order": "abcd",
|
||||||
"auto_join": true
|
"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
|
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
|
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
|
automatically joined by members of the space: see
|
||||||
[below](#auto-joined-children).
|
[below](#auto-joined-children).
|
||||||
|
|
||||||
2. Separately, rooms can claim a parent via the `m.space.parent` state
|
2. Separately, rooms can claim parents via the `m.space.parent` state
|
||||||
event:
|
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
|
```js
|
||||||
{
|
{
|
||||||
"type": "m.space.parent",
|
"type": "m.space.parent",
|
||||||
"state_key": "",
|
"state_key": "!space:example.com",
|
||||||
"content": {
|
"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
|
Parents where `via` is not present are ignored.
|
||||||
start peeking into the parent space, enabling it to find other rooms in
|
|
||||||
that space and group them together.
|
`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
|
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`
|
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
|
Where the parent space also claims a parent, clients can recursively peek
|
||||||
into the grandparent space, and so on.
|
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
|
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
|
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
|
relationships to exist, so that the space can be discovered from the room, and
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue