MSC1840 is out again.
@@ -39,11 +39,10 @@ within the space are determined by state events within the space-room.
Spaces are referred to primarily by their alias, for example
`#foo:matrix.org`.
-Space-rooms are distinguished from regular messaging rooms by the `m.room.type`
-of `m.space` (see
-[MSC1840](https://github.com/matrix-org/matrix-doc/pull/1840)). This allows
-clients to offer slightly customised user experience depending on the purpose
-of the room.
+Space-rooms are distinguished from regular messaging rooms by the presence of a
+`type: m.space` property in 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 may have `m.room.name` and `m.room.topic` state events in the same
way as a normal room.
@@ -69,8 +68,8 @@ 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 event containing the type `m.space`, to allow clients to discern
-whether an invite is to a space-room or not.
+include the `m.room.create` event, to allow clients to discern whether an
+invite is to a space-room or not.
XXX: Should we also include a MSC2946 summary of the space in the invite too?
@@ -279,9 +278,6 @@ One way this might be implemented is:
## Dependencies
- * [MSC1840](https://github.com/matrix-org/matrix-doc/pull/1840) for room
- types.
-
* [MSC2753](https://github.com/matrix-org/matrix-doc/issues/2753) for
effective peeking over the C/S API.
@@ -312,6 +308,15 @@ These dependencies are shared with profiles-as-rooms
different querying users. (It may be possible to simulate this behaviour
using smaller spaces).
+## Rejected alternatives
+
+### Use a separate state event for type of room
+
+[MSC1840](https://github.com/matrix-org/matrix-doc/pull/1840) proposes the use
+of a separate `m.room.type` state event to distinguish different room
+types. This implies that rooms can dynamically switch between being a Space,
+and being a regular non-Space room. That is not a usecase we consider useful,
+and allowing it would impose significant complexity on client implementations.
## Unstable prefix
@@ -320,7 +325,8 @@ development:
Proposed final identifier | Purpose | Development identifier
------------------------------- | ------- | ----
-`m.space` | room type | `org.matrix.msc1772.space`
+`type` | property in `m.room.create` | `org.matrix.msc1772.type`
+`m.space` | value of `type` in `m.room.create` | `org.matrix.msc1772.space`
`m.space.child` | event type | `org.matrix.msc1772.space.child`
`m.space.parent` | event type | `org.matrix.msc1772.space.parent`
