incorporate travis feedback
@@ -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
