MSC3137: Define space room type, subset of MSC1772 #3137
Conversation
turt2live
added
client-server
| 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. |
There was a problem hiding this comment.
Is there a reason this section made it in? Feels weird given the definition of a 'room list' didn't make it.
There was a problem hiding this comment.
(I assume this applies to lines 32-48)
It might be best to remove this section for now and instead position the MSC as introducing a type (in counter to MSC1840, but without the bloat of Filter APIs), with m.space as a reserved identifier for something called "Spaces". This way, the spec has a path forward that disassociates the MSC from 1772.
| 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. |
There was a problem hiding this comment.
A bit of guidance on what a client that understands only this MSC might do could be nice, eg. display the room or hide it.
|
|
||
| All other behaviours, additional functionality, endpoints, state events are to be | ||
| defined by other MSCs to allow the greatest flexibility. | ||
|
|
There was a problem hiding this comment.
Just to fill in the bits needed for FCP to be considered:
| The `type` contains a normal identifier ([MSC2758](https://github.com/matrix-org/matrix-doc/pull/2758)) | |
| and should be assumed to be of a generic (ie: conversational) type when not present. | |
| 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. |
There was a problem hiding this comment.
(I assume this applies to lines 32-48)
It might be best to remove this section for now and instead position the MSC as introducing a type (in counter to MSC1840, but without the bloat of Filter APIs), with m.space as a reserved identifier for something called "Spaces". This way, the spec has a path forward that disassociates the MSC from 1772.
|
|
||
| Proposed final identifier | Purpose | Development identifier | ||
| ------------------------------- | ------- | ---- | ||
| `type` | property in `m.room.create` | `org.matrix.msc1772.type` |
There was a problem hiding this comment.
That would mean we lose all existing spaces twice
There was a problem hiding this comment.
oh - i see, #1840 is mutable typing, whereas this is introducing immutable typing.
Co-authored-by: Travis Ralston <travpc@gmail.com>
| @@ -0,0 +1,91 @@ | |||
| # Proposal for Matrix Spaces room type | |||
There was a problem hiding this comment.
I'm somewhat with @erikjohnston in being confused on what it means to define a 'type of room to be a space' in advance of defining what a space actually is. Does this really need to be split out from #1772? Can we get #1772 through FCP instead?
There was a problem hiding this comment.
If we can then even better. This was written solely for the worry that that would take too long
|
Closing with the dream of MSC1772 passing FCP asap |
turt2live
added
abandoned
Rendered