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

MSC1840: Typed rooms #1840

Open
wants to merge 8 commits into
base: old_master
Choose a base branch
from

Conversation

jfrederickson
Copy link

@jfrederickson jfrederickson commented Feb 3, 2019

Rendered

Signed-off-by: Jonathan Frederickson jonathan@terracrypt.net

FCP tickyboxes

@jfrederickson jfrederickson changed the title Typed rooms MSC1840: Typed rooms Feb 3, 2019
Signed-off-by: Jonathan Frederickson <jonathan@terracrypt.net>
@anoadragon453
Copy link
Member

One alternative to a new state event is just adding a new field into the m.room.create's creation content.

@jfrederickson
Copy link
Author

That would preclude changing the type of a room after creation, right? Then again that may be desirable... not sure.

@anoadragon453
Copy link
Member

Indeed, but yes not sure if the usecase requires such an ability. I at least don't see it for the profiles or communities as rooms use case.

But I'll leave it up for others to chime in.

@jfrederickson
Copy link
Author

jfrederickson commented Feb 3, 2019

I can think of one in particular: this might also be useful for distinguishing between IM-style rooms and long-form style rooms. (Think Matrix as an email protocol for example.) I think it might make sense for a room to change types down the line between two text messaging use-cases.

This might also be useful for Fractal's Banquet/Barbecue split, though I'm less sure about that one.

I did have another thought though... would it make sense for rooms to have multiple types?

@turt2live turt2live added proposal-in-review proposal A matrix spec change proposal labels Feb 3, 2019
@Half-Shot
Copy link
Contributor

I'd argue for not putting more things into m.room.create unless it MUST be a static value for the limetime of the room i.e. version. Anything that could change should be it's own state. I can see reasons to want to change the type at some point.

@jcgruenhage
Copy link
Contributor

What do people think about having multi purpose rooms? For example if a room is used for hosting a git project in matrix, using the same room for discussion about that project would be desirable, because it allows us to use the same alias there.

to specific room types, but that feels like it's beyond the scope of
this proposal at this point.

## Examples
Copy link
Contributor

Choose a reason for hiding this comment

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

If the type is omitted, would we consider m.room_type.messaging to be the default type given Matrix's history.

Choose a reason for hiding this comment

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

It would be wrong for this part of the spec to state a default value unconditionally. Concretely, it would be wrong for a general purpose library or SDK to report an unconditionally specified default value when the type is omitted.

A typical IM client, working with typical existing IM rooms, will presumably by default (when the type is unspecified) assume it's an IM messaging room; whereas the default assumption in an IoT client will be something else; and there could be deployment scenarios where all rooms have an explicit room type and no default is needed and the client software developed for that scenario reports an error or ignores the room if no type is provided.

A default value is in the eye of the beholder, not absolute.


## Solution

The proposal is to add a new state event, `m.room.type`, to define the
Copy link
Contributor

Choose a reason for hiding this comment

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

I realise this may bloat the proposal, but I feel like we should define a few common types in the spec and how clients should react to them, at least at a high level. I.e. m.room_type.messaging should present users with a chat-room like interface, wheras m.room_type.iot.* may just show a simplified view.

Copy link

Choose a reason for hiding this comment

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

Maybe a type like m.room_type.nsfw could be used to filter out explicit content. In that case, would it make sense to allow public directory filtering by room type?

Copy link
Contributor

Choose a reason for hiding this comment

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

Marking something as nsfw is more like a tag than a type IMO, because you can have nsfw content in different types of room. I think nsfw tagging (or content notices/warnings to be more generic) are a separate topic.

Choose a reason for hiding this comment

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

Counter-examples are useful too. It's worth included a counter-example like this in the spec to illustrate one of the boundaries of applicability.

Copy link
Author

@jfrederickson jfrederickson Oct 28, 2020

Choose a reason for hiding this comment

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

Added a few examples.

For what it's worth... nsfw might still be a useful type to have if it's possible to have multiple types associated with a room? In other words, rather than:

"content": {
    "type": "m.messaging"
}

Use an array:

"content": {
    "types": ["m.messaging", "m.nsfw"]
}

...though regardless of the types in particular, I'd like to consider the option of a types array. @jcgruenhage brought this up outside of a thread, and I think I agree with it:

What do people think about having multi purpose rooms? For example if a room is used for hosting a git project in matrix, using the same room for discussion about that project would be desirable, because it allows us to use the same alias there.

Copy link
Member

Choose a reason for hiding this comment

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

Allowing multiple types at once would cause massive confusion especially in clients which denormalize data. Imagine a room marked as IoT, Messaging, a Matrix Space and a User Profile room, how do you store anything and what do you even render?

@n1trux
Copy link

n1trux commented Jan 20, 2020

What do people think about having multi purpose rooms?

Could that be achieved by setting a "default message type" and have other (non-chat) clients send other events/messages which aren't shown by a chat client?

There could be a difference between "allowed message types" and "room type" aka "default message type" – for example m.room.type.allowed, m.room.type.disallowed, m.room.type.default instead of a "single" room type. This could also be used for @KB1RD's idea of having NSFW messaging allowed/disallowed, possibly with added metadata like proposed by #1767.

There could also be a permissions/tag system for posting messages of different kinds, e.g. "only devices with tag iot or power level ≥50 can post m.message_type.iot". Is there an MSC for tagging users apart from power levels?

@jfrederickson
Copy link
Author

I'd like to point out that some possible room types are independent of the message types meant to be used within them. For example, if room types were used to separate small group chats from larger collaborative chats (think Fractal's Banquet vs. Barbecue), the messages in each would be m.room.messages, but the room type could be used to filter out certain chats from certain clients.

Similarly, if you were to use Matrix for an email-style asynchronous chat interface, the messages may also be m.room.messages, but you might not want to show all the chat-style messages in that client (and vice-versa).

@Sorunome
Copy link
Contributor

It might be a good idea to also add this to the invite state events, which are sent along if you invite somebody

@jcgruenhage
Copy link
Contributor

I'd love to see this happening, and considering it's quite a small change, could this maybe be squished in soon?

@Sorunome
Copy link
Contributor

Sorunome commented Jun 2, 2020

If extensible profiles as rooms is "type:core", shouldn't this also be "type:core", as the entire point of this MSC is to flag different-kind rooms? And, well, this is a core function needed if, well, as newvector seems to want to push matrix, that matrix is more than just a chat....you need typed rooms for that, then.

@anoadragon453
Copy link
Member

@Sorunome Typed rooms are not a hard requirement of extensible profiles. It's possible to point at a generic room, say "this is my profile room", and have everything work. Alternatively you could simply say !andrewm:amorgan.xyz is my profile room.

There are lots of different ways to solve that particular problem. When this MSC was labelled, it was determined that it wasn't a hard requirement of any current "core" MSCs.

@Sorunome
Copy link
Contributor

Sorunome commented Jun 2, 2020

@anoadragon453 and then there will be bug reports of the profile room showing up in your normal chat rooms....

@turt2live
Copy link
Member

Not if we fix peeking first.

@Sorunome
Copy link
Contributor

Sorunome commented Jun 2, 2020 via email

@turt2live
Copy link
Member

Possibly, though all this feedback is on the wrong MSC and not in a thread.

@MurzNN

This comment has been minimized.

@grinapo

This comment has been minimized.

@aledomu

This comment has been minimized.

I'm unclear on whether this should be done by the client on room
creation or by the server as part of `createRoom`. Open to feedback
here.
Initially I was considering the default to be `m.messaging`, but
@julianfoad brings up a good point that this isn't necessarily a good
assumption. I'm inclined to leave the decision of what to do with
untyped rooms up to the clients, while recommending that they set room
types for new rooms going forward.
@win-some
Copy link

win-some commented Dec 4, 2020

Is there any relation between a room type and a feature profile, from Client-Spec 13.1? It seems to me that as other applications spring up it might be worth having a process to formalize how different types are expected to behave.

## Solution

The proposal is to add a new state event, `m.room.type`, to define the
intended usage of the room. Some example use cases for this:
Copy link

@joepie91 joepie91 Jan 3, 2021

Choose a reason for hiding this comment

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

I have a feeling that a lot of the discussions surrounding the exact semantics of this feature, revolve around the same problem: the premise of the MSC is wrong in a subtle but important way.

This MSC presents the room type as representing the "intended usage" - but is that really what anyone cares about?

  • Users will infer the intended usage from context (title, description, existing content, what they have been told by others, etc.). They don't need a room type property.
  • Client developers don't care about the intended usage, exactly, rather they care about how the room should be presented to the user and/or what additional features and capabilities should be attached to it.
  • Bot developers don't care about "intended usage" at all, they just care about whether there is actionable content in the room. That's usually pretty close to "how should it be presented to the user", since the purpose of bots is typically to assist users in their desired usage of a room.
  • Homeserver developers don't care about "intended usage" either. They only care about the event types contained therein, and whether there are special processing rules or storage optimizations for those event types.

"What a room contains" is already appropriately addressed by the event types themselves, so should be out-of-scope for this MSC. Likewise, human context is out-of-scope for MSCs entirely. This leaves one thing that people do actually care about: how should a room be presented to the user?

This perspective also makes the question of "multiple types" (ie. room tags) easier to address: yes, supporting multiple tags makes sense, because rooms may benefit from multiple representations. For example, a room for a hackerspace may contain both:

  1. Conversation and chatter between members of the hackerspace, and
  2. Sensor data for the environmental sensors in the corresponding physical space

It would conceptually make sense to group these messages together into a single room that represents "the hackerspace" as a physical space in a virtual environment. Yet there are multiple ways to represent this room; either as a stream of (visualized?) sensor data, or as a chatroom.

In this situation, some clients may only care about the sensor data, some only about the chatroom, some about both. A client can freely pick those tags which it can support in terms of representation to the end-user, and where necessary, make a contextual determination of which representation it considers the "primary" one (eg. chat by default, sensor data in a separate panel).

(Such a determination could be made easier by considering the tags to be ordered, so that a room can - on a protocol level - express a priority order for its tags, if it has multiple.)

As another example of multiple-tag application, communicating that nested/threaded rendering is desirable if possible can be done with an additional tag, without needing to give up whichever tag a 'normal' Matrix client would be looking for to render a chatroom. Ordering-wise, that would likely go before the normal messaging tag to express a preference for nested view.

It also addresses the question of type mutability: yes, the intended representations of a room can change. The hypothetical hackerspace members in aforementioned example might decide that they actually hate sensors (Internet of Shit, right?), and stop publishing sensor data and remove the corresponding room tag. In that case, a client might decide to no longer (prominently) offer the sensor view from that point onwards.

And to address upfront how "intended representation" is not already handled by event types: while there is relative freedom in choice of event type for custom non-spec usecases, this is not true for usecases that are covered by the spec.

For example, regular messages are supposed to be represented with m.message and probably an m.text kind, even if they should get a special representation such as in an e-mail thread. The ability to apply "room representation tags" to this end would help to resolve this ambiguity.

It would also help to communicate to clients that they should expect a certain kind of content, rather than needing to infer this from whatever events are currently in the client's buffer, which might result in additional representations suddenly popping up when the user navigates back through the room history.

Copy link

Choose a reason for hiding this comment

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

Addendum: while the "multiple representations" requirement could also be implemented by declaring that each representation should have its own dedicated room, I feel that that solution would be inferior:

  1. It does not really simplify things at all. You would still want to link together the representations semantically, so you would need some sort of 'room link'. Now, instead of a flat array of (string) tags, the client needs to deal with an array of room references and correlate cross-room state.
  2. Having separate representations as separate rooms actually introduces more complexity; not only would it raise questions of handling shared membership state (like are being encountered in the Spaces proposal), it would also make it difficult to represent eg. references between events that belong to different representations, share events between representations, and just overall introduce more need for cross-referencing logic in clients.

Aside from those points, I feel that the broader concept of multiple room representations could neatly complement Widgets; whereas Widgets are suitable for wholesale-embeddable 'applets' without long-term Matrix-side state, this design would work well for usecases where the client is expected to do the representation itself, and it is desirable to persist/replicate the state in the same way as any other Matrix event.

@karmanyaahm
Copy link

I had an idea kind of like the following, and it would be really nice if room types became a thing in Matrix

A project wants to use Matrix to allow a user to interact with an
IoT lightbulb, but doesn't want the rooms and control messages used
for this to clutter up the user's Element room list
(com.example.manufacturer.iot.light)

@bleonard252
Copy link

Room types are now in the spec

@clokep
Copy link
Contributor

clokep commented Jun 16, 2024

Room types are now in the spec

I think with them being added in MSC1772 we should likely just close this.

@mscbot fcp close

@mscbot
Copy link
Collaborator

mscbot commented Jun 16, 2024

Team member @clokep has proposed to close this. The next step is review by the rest of the tagged people:

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

@mscbot mscbot added proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. disposition-close labels Jun 16, 2024
@turt2live turt2live added this to Needs idea feedback / initial review in Spec Core Team Backlog via automation Jun 17, 2024
@turt2live turt2live moved this from Needs idea feedback / initial review to Ready for FCP ticks in Spec Core Team Backlog Jun 17, 2024
@turt2live
Copy link
Member

This MSC is not really the same as the room types which are in the spec. In the spec, room types are immutable - this can cause problems with some features.

I'd prefer to see the author's arguments for mutable room types be expanded. -0.8 in favour of FCP.

@dbkr
Copy link
Member

dbkr commented Jun 18, 2024

I agree, there's semantic overlap with the type for rooms the spec already has, and given the discussion of whether NSFW would be a use for this, it seems the intent isn't very clear.

@richvdh
Copy link
Member

richvdh commented Jun 18, 2024

If @jfrederickson (or some other volunteer) is still keen to pursue this and has usecases in mind that aren't well served by the room types in the spec, very happy to see this be updated and kept open.

Assuming that's not the case, I think we should close it to reduce noise and confusion.

@uhoreg
Copy link
Member

uhoreg commented Jun 18, 2024

I agree with Rich. The examples given in this MSC look like they can be served by the room type that is currently specced. And while the semantics of the room type in this MSC and the specced room type are not the same (e.g. with regards to immutability, additional properties, etc.), I think we'd need to see a use case that cannot be served by the currently-specced room type as justification for keeping this open. If we do close this and someone does want to do something that can only be handled by this MSC, they can re-propose it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-close kind:core MSC which is critical to the protocol's success 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 proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period.
Projects
Spec Core Team Backlog
  
Ready for FCP ticks
Development

Successfully merging this pull request may close these issues.

None yet