Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-04 05:13:42 +01:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

incorporate travis feedback

Browse source
This commit is contained in:
Matthew Hodgson 2021-04-29 22:24:12 +01:00
parent 0d71150424
commit 7432d254c6
1 changed files with 15 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -37,16 +37,18 @@ unspecified.
Each space is represented by its own room, known as a "space-room". The rooms
within the space are determined by state events within the space-room.
Space-rooms are distinguished from regular messaging rooms by the presence of a
`type: m.space` property in the content of the `m.room.create` event. This allows clients to
offer slightly customised user experience depending on the purpose of the
room. Currently, no server-side behaviour is expected to depend on this property.
Space-rooms are distinguished from regular messaging rooms by the presence of
a `'type': 'm.space'` property in the content of the `m.room.create` event.
The value of the `type` property uses the Standardised Identifier Grammar from
MSC #2758. This allows clients to offer slightly customised user experience
depending on the purpose of the room. Currently, no server-side behaviour is
expected to depend on this property.
As with regular rooms, public spaces are expected to have an alias, for example
`#foo:matrix.org`, which can be used to refer to the space.
Space-rooms may have `m.room.name` and `m.room.topic` state events in the same
way as a normal room.
Space-rooms may have `m.room.name`, `m.room.avatar` and `m.room.topic` state
events in the same way as a normal room.
Normal messages within a space-room are discouraged (but not blocked by the
server): user interfaces are not expected to have a way to enter or display
@ -67,10 +69,9 @@ to see the directory of rooms within the space by peeking into the space-room
(thus avoiding the need to add `m.room.member` events to the event graph within
the room).
Join rules, invites and 3PID invites work as for a normal room, with the
exception that `invite_state` sent along with invites should be amended to
include the `m.room.create` event, to allow clients to discern whether an
invite is to a space-room or not.
Join rules, invites and 3PID invites work as for a normal room. In order for
clients to distinguish space invites from room invites, all invites must now
include the `m.room.create` event in their `invite_state`.
### Relationship between rooms and spaces
@ -111,7 +112,7 @@ relationship can be expressed in one of two ways:
}
```
Children where `via` is not present are ignored.
Children where `via` is not present or invalid (not an array) 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
@ -121,8 +122,8 @@ relationship can be expressed in one of two ways:
lexicographic order of their `room_id`s in case of equal
`origin_server_ts`. `order`s which are not strings, or do not consist
solely of ascii characters in the range `\x20` (space) to `\x7F` (`~`), or
consist of more than 50 characters, are forbidden and should be ignored if
received.)
consist of more than 50 characters, are forbidden and the field should be
ignored if received.)
2. Separately, rooms can claim parents via the `m.space.parent` state
event.
@ -142,7 +143,7 @@ relationship can be expressed in one of two ways:
}
```
Parents where `via` is not present are ignored.
Parents where `via` is not present or invalid (not an array) 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