From a88575765979b7b7952be654e4ab4ef36080ea0c Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Tue, 20 Apr 2021 12:01:13 +0100 Subject: [PATCH 1/3] MSC3137, subset of MSC1772 to define space room type --- proposals/3137-spaces-room-type.md | 91 ++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 proposals/3137-spaces-room-type.md diff --git a/proposals/3137-spaces-room-type.md b/proposals/3137-spaces-room-type.md new file mode 100644 index 00000000000..ed5fe31e7ce --- /dev/null +++ b/proposals/3137-spaces-room-type.md @@ -0,0 +1,91 @@ +# Proposal for Matrix Spaces room type + +This MSC is a subset of +[MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772). + +https://github.com/matrix-org/matrix-doc/pull/1840#issuecomment-460070485 + +## Background and objectives + +As part of progressing [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) +we have identified that we can obtain the greatest flexibility with the lowest risk by +separating out the space room type definition into its own MSC and get it stabilised +before the rest of the proposals. + +That way any migrations therein do not need to burn and create new rooms, can just +migrate state events within the otherwise stable space rooms, this helps avoid yet +another room upgrade cycle, which is a very degraded experience, in the process of +getting Spaces out of the door. + +## Proposal + +Each space is represented by its own room, known as a "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. + +All other behaviours, additional functionality, endpoints, state events are to be +defined by other MSCs to allow the greatest flexibility. + +### Membership of spaces + +Users can be members of spaces (represented by `m.room.member` state events as +normal). The existing [`m.room.history_visibility` +mechanism](https://matrix.org/docs/spec/client_server/r0.6.1#room-history-visibility) +controls whether membership of the space is required to view the room list, +membership list, etc. + +"Public" or "community" spaces would be set to `world_readable` to allow clients +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. + +## Related MSCs + + * [MSC1772](https://github.com/matrix-org/matrix-doc/issues/1772): Matrix + spaces. + + * [MSC2946](https://github.com/matrix-org/matrix-doc/issues/2946): Spaces + Summary API. + + * [MSC3060](https://github.com/matrix-org/matrix-doc/issues/3060): Room + subtyping. + + * [MSC1840](https://github.com/matrix-org/matrix-doc/issues/1840): Typed + rooms. + +## Security considerations + +None at present. + +## Potential issues + +None at present. + +## 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 + +The following mapping will be used for identifiers in this MSC during +development, they are inherited from MSC1772 to prevent yet another +breaking change: + +Proposed final identifier | Purpose | Development identifier +------------------------------- | ------- | ---- +`type` | property in `m.room.create` | `org.matrix.msc1772.type` +`m.space` | value of `type` in `m.room.create` | `org.matrix.msc1772.space` From 69fdca94a70705a0c3d7af0351fbe11d1ca985f0 Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Thu, 22 Apr 2021 08:41:23 +0100 Subject: [PATCH 2/3] Update 3137-spaces-room-type.md --- proposals/3137-spaces-room-type.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3137-spaces-room-type.md b/proposals/3137-spaces-room-type.md index ed5fe31e7ce..d09d5415896 100644 --- a/proposals/3137-spaces-room-type.md +++ b/proposals/3137-spaces-room-type.md @@ -55,7 +55,7 @@ invite is to a space-room or not. * [MSC2946](https://github.com/matrix-org/matrix-doc/issues/2946): Spaces Summary API. - * [MSC3060](https://github.com/matrix-org/matrix-doc/issues/3060): Room + * [MSC3088](https://github.com/matrix-org/matrix-doc/issues/3088): Room subtyping. * [MSC1840](https://github.com/matrix-org/matrix-doc/issues/1840): Typed From c284a0f2c4cd7daa34ec97da56862688e754729d Mon Sep 17 00:00:00 2001 From: Michael Telatynski <7t3chguy@gmail.com> Date: Wed, 28 Apr 2021 20:08:42 +0100 Subject: [PATCH 3/3] Update proposals/3137-spaces-room-type.md Co-authored-by: Travis Ralston --- proposals/3137-spaces-room-type.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3137-spaces-room-type.md b/proposals/3137-spaces-room-type.md index d09d5415896..29d3a86bd2f 100644 --- a/proposals/3137-spaces-room-type.md +++ b/proposals/3137-spaces-room-type.md @@ -1,6 +1,6 @@ # Proposal for Matrix Spaces room type -This MSC is a subset of +This MSC is broken out from [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772). https://github.com/matrix-org/matrix-doc/pull/1840#issuecomment-460070485