Skip to content
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

Draft
wants to merge 1 commit into
base: old_master
Choose a base branch
from
Draft

Conversation

turt2live
Copy link
Member

@turt2live turt2live commented Apr 1, 2021

Rendered

Usecase implementation: matrix-org/matrix-js-sdk#1732

@turt2live turt2live changed the title Room subtyping MSC3088: Room subtyping Apr 1, 2021
@turt2live turt2live added client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal labels Apr 1, 2021
@turt2live turt2live marked this pull request as draft April 1, 2021 20:55
[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.*
Copy link
Contributor

@ShadowJonathan ShadowJonathan Apr 2, 2021

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not seeing how any of that would benefit from subtypes tbh. HummingBard would use MSC1840, Twitter feeds don't need a purpose type (they want extensible events instead), voice channels would also be MSC1840 most likely, and data storage rooms like profiles would also use MSC1840

Copy link
Contributor

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

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

Copy link

@gleachkr gleachkr Jan 22, 2022

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MSC1840 is still proposing a mutable m.room.type state event fwiw, with MSC1772 having gone with a type field in m.room.create, being immutable. Should we rather refer to 1772 here?

Copy link
Member Author

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)

@turt2live turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021
@turt2live turt2live self-assigned this Jun 8, 2021
turt2live added a commit to matrix-org/matrix-js-sdk that referenced this pull request Jun 10, 2021
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

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants