MSC1840: Typed rooms

[jfrederickson]

Rendered

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

FCP tickyboxes

[anoadragon453]

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

[jfrederickson]

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

[anoadragon453]

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]

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?

[Half-Shot]

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]

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.

[Half-Shot]

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

[julianfoad]

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.

[Half-Shot]

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.

[KB1RD]

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?

[jcgruenhage]

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.

[julianfoad]

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.

[jfrederickson]

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.

[t3chguy]

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]

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]

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]

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

[jcgruenhage]

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

[Sorunome]

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]

@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]

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

[turt2live]

Not if we fix peeking first.

[Sorunome]

So....rather do a hacky way to hide non-chat rooms and then, later on, introduce the proper way, forcing clients to have backwards compability for all eternity? Am 2. Juni 2020 18:31:24 MESZ schrieb Travis Ralston <notifications@github.com>:

…

Not if we fix peeking first. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1840 (comment)

[turt2live]

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

[win-some]

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.

[joepie91]

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.

[joepie91]

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]

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]

Room types are now in the spec

[clokep]

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]

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

• @clokep
• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @tulir
• @erikjohnston
• @KitsuneRal

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.

[turt2live]

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]

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]

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]

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.

[ara4n]

I'm on the fence on this one, fwiw. I'm not seeing a good argument in the MSC as to why mutable room types are actually needed, and it's not clear that we've missed out enormously over the years for not having them. The UX needed in clients to go and either let users convert rooms between different types, or the confusing UX caused by rooms suddenly winking out of existence as they get converted between different types, feels like avoidable confusion without an obvious use case, given you can always create a room of the right time. It almost feels icky like casting types in C, given the events in the room will suddenly get 'cast' into the new type, potentially creating a whole sort of general mishmash if a room keeps fluxing between types.

On the other hand, 17 people upvoted this as a good idea, so presumably folks did have a use case for this at the time. (In fact, I vaguely remember encouraging jfred to open it in the first place).

So, everyone: this is your last chance to make a case for mutable room types.

[jfrederickson]

Apologies, meant to respond to this earlier. Personally the currently specified immutable room types are sufficient for the cases I was concerned with, especially since we already have an example of a room type (m.space) that's treated differently by clients. I'm fine with closing this one.