-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC3088: Room subtyping #3088
base: old_master
Are you sure you want to change the base?
MSC3088: Room subtyping #3088
Conversation
[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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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