MSC3088: Room subtyping #3088
MSC3088: Room subtyping #3088
Conversation
turt2live
added
client-server
| [MSC1840](https://github.com/matrix-org/matrix-doc/pull/1840) a bit. | ||
|
|
||
| *Author's note: The use cases for this are somewhat weak. Suggestions for what sorts of problems this | ||
| MSC might solve are appreciated.* |
There was a problem hiding this comment.
I can think of a few:
- HummingBard "spaces" (communities for posts), both user-profile and normal
- I have seen someone mention using rooms for "twitter feed"-esc socialization, similar to HummingBard's post spaces
- voice channels, video channels, "stage" channels (few-send-many-receive, like a "stage")
- internal rooms; think extensible profiles, data between servers (decentralized aliasing?), and misc
There was a problem hiding this comment.
There was a problem hiding this comment.
I would get the point of using this MSC for stage rooms as a subtype of voice/video rooms
There was a problem hiding this comment.
Another usecase for this would be in making git repository matrix rooms. For example the space and room would have the main type of a git repo saving a url, server, name, author, etc. of the repo. The subtype for the room would be if it's an issue, pr, discussion, etc. which we might want to move from one to another
There was a problem hiding this comment.
Another possible use case is marking up resources using matrix. The idea in that proposal is that the main space represents a resource to be annotated or discussed, and the child rooms are different discussions of the resource (with the m.space.parent events representing annotations). MSC3574 currently puts this data in m.room.create, but mainly because that way it can get into the stripped state. If room subtypes were available in stripped state or for use in filtering, that would be useful for annotation-oriented clients.
Even if MSC1840 was available, it might make sense to have m.room.purpose: m.markup.pdf alongside m.room.type: m.markup - one use for this extra data would be a chat client that wanted to avoid cluttering its interface with markup spaces could ignore all rooms with mutable type m.markup while annotation clients that are only interested in pdfs could whitelist rooms with purpose m.markup.pdf.
Though maybe this is a little contrived, since maybe a chat client like that would want to avoid all rooms with unknown mutable type?
You could also use this proposal to distinguish between annotation spaces that should also be presented as chat spaces, and annotation spaces that should only be presented as annotation spaces.
| # MSC3088: Room subtyping | ||
|
|
||
| Rooms have traditionally been used for conversation, however in recent times it has become more relevant | ||
| that rooms can serve non-conversational purposes. [MSC1840](https://github.com/matrix-org/matrix-doc/pull/1840) |
There was a problem hiding this comment.
probably, yes. This MSC in fact might end up getting merged into 1840 if we can agree on terminology, but first we need a valid usecase for subtyping (which is on the horizon)
turt2live
added
the
needs-implementation
MSC: matrix-org/matrix-spec-proposals#3089 Includes part of MSC3088 (room subtyping): matrix-org/matrix-spec-proposals#3088 The NamespacedValue stuff is borrowed from the Extensible Events implementation PR in the react-sdk as a useful thing to put here. When/if the MSCs become stable, we'd convert the values to enums and drop the constants (or keep them for migration purposes, but switch to stable). This flags the whole thing as unstable because it's highly subject to change.
|
|
||
| ## Potential issues | ||
|
|
||
| Rooms having multiple purposes, or purposes which conflict with the room's type, might be confusing |
There was a problem hiding this comment.
Maybe s/multiple purposes/multiple conflicting purposes/ here, to clarify that multipurpose rooms are still part of the proposal?
Rendered
Usecase implementation: matrix-org/matrix-js-sdk#1732