matrix-spec-proposals
matrix-spec-proposals copied to clipboard
matrix-org
MSC1840: Typed rooms
One alternative to a new state event is just adding a new field into the m.room.create's creation content.
That would preclude changing the type of a room after creation, right? Then again that may be desirable... not sure.
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.
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?
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.
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.
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?
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).
It might be a good idea to also add this to the invite state events, which are sent along if you invite somebody
I'd love to see this happening, and considering it's quite a small change, could this maybe be squished in soon?
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.
@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.
@anoadragon453 and then there will be bug reports of the profile room showing up in your normal chat rooms....
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: https://github.com/matrix-org/matrix-doc/pull/1840#issuecomment-637666817
Possibly, though all this feedback is on the wrong MSC and not in a thread.
If we plan adding types to rooms for groups, profiles, etc - maybe good time to rename base Matrix entity room to something more relevant, like node? And use rooms, groups, communities, profiles, banlists, etc as subset of base entity node.
For not break old behavior, we can keep m.room.* API queries as alias of m.node.*.
to something more relevant, like
node?
It seems like the original irc naming of channel was quite appropriate, it's way better describing the concept than "node".
I don't get what is this actually for and how it differs from a tag-based approach in that sense.
Chiming in on default types:
I’m evaluating to use matrix as a basis for some apps that has agents interacting with other agents on behalf of their users. That includes spawning several rooms with the right users and specific power levels. If the user can see these in element they could not be aware the consequences of leaving them or changing any state in them. A workaround would be to put in a sticky message saying “this room is managed by XYZ do not leave it” and hiding it in low priority but that’s a dirty workaround.
As such, this MSC is exactly what I wanted to propose as well. There needs to be at least one type for “not managed directly by the user”, and that should include invites to the room.
If clients can define their own room types, and element/other chat clients filtered for the .messaging, that would also work.
We were already forced to implement this at our work long ago.
This should not be type:feature, but type:core. Matrix supposively being more than just a chat protocol, this is crucial. How else should you mark e.g. groups-as-rooms as groups? Or profiles-as-rooms as profiles? By the presence of a specific state event? What about clients, will they have to keep a list of state events to hide in their room list indefinitely, a list that will grow over time? That sounds like very bad spec design.
Are typed rooms subject to bike-shedding? Yes, yes they are, no doubt. But, that is what we have a core spec team for, to work on these important things. Implementation-wise typed rooms are trivial, even.
Just look at how many here are asking for it, and to re-iterate, we were forced at our work already long ago, simply because the need is there, we had to, well, mark rooms as different types.
MSC #2773 is an alternative to this MSC (just because github did not yet know about the connection)
I also can't see any use case for this, we even want the DM-status of a conversation to be immutable in their new incarnation.
As a user, soru had multiple times that some people were invited to a DM and that DM then turned into a group chat over time. So, making that mutable does make sense.
I also can't see any use case for this, we even want the DM-status of a conversation to be immutable in their new incarnation.
As a user, soru had multiple times that some people were invited to a DM and that DM then turned into a group chat over time. So, making that mutable does make sense.
Have commented on the Canonical DMs MSC to clarify this
I'm very interested in this proposal in the context of MSC1772, but am not going to try to read through 30 unthreaded comments to figure out which have been addressed and which not. As with https://github.com/matrix-org/matrix-doc/pull/1772#issuecomment-712780558: if folks have outstanding comments, please make them on the document, not the PR.
@jfrederickson are you interested in updating the proposal following the feedback from the community, or should we take it on within the core matrix team?
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.
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)
