MSC1840: Typed rooms

[jfrederickson]

Rendered

Signed-off-by: Jonathan Frederickson [email protected]

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 <[email protected]>:

…

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.

[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.

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[mscbot]

The final comment period, with a disposition to close, as per the review above, is now complete.