From 871dd4417c87e220d98f210c5779588c3f55d67b Mon Sep 17 00:00:00 2001 From: Jonathan Frederickson Date: Sun, 3 Feb 2019 11:54:32 -0500 Subject: [PATCH 1/8] Add proposal for room type state event Signed-off-by: Jonathan Frederickson --- proposals/1840-room-types.md | 85 ++++++++++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 proposals/1840-room-types.md diff --git a/proposals/1840-room-types.md b/proposals/1840-room-types.md new file mode 100644 index 00000000000..279e25df44e --- /dev/null +++ b/proposals/1840-room-types.md @@ -0,0 +1,85 @@ +- **Author**: Jonathan Frederickson +- **Created**: 2019-02-03 + +# Room Types + +## Problem + +The Matrix protocol currently has no mechanism to differentiate rooms +from each other based on their intended use case. There have been +proposals such as +[MSC1769](https://github.com/matrix-org/matrix-doc/pull/1769) and +[MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) that use +rooms for purposes other than the traditional messaging +use-case. Without a mechanism to differentiate them from messaging +rooms, clients will display them as they do any other room unless they +work around this limitation on a case-by-case basis. + +## Solution + +The proposal is to add a new state event, `m.room.type`, to define the +intended usage of the room. + +This by itself could be used by a client to properly display rooms +based on their intended usage. However, to optimize the use of +bandwidth for an account used for varying purposes, the filter API +could then be extended to allow for filtering the rooms that are +returned from a sync based on room type. (A client meant for receiving +IoT device data, for example, has no need to receive messages destined +for that account, nor to be aware at all that messaging rooms exist.) + +N.B. There's an opportunity here to additionally scope access tokens +to specific room types, but that feels like it's beyond the scope of +this proposal at this point. + +## Examples + +### m.room.type + +```json +{ + "content": { + "type": "m.room_type.messaging" + }, + "event_id": "$143273582443PhrSn:domain.com", + "origin_server_ts": 1432735824653, + "room_id": "!jEsUZKDJdhlrceRyVU:domain.com", + "sender": "@example:domain.com", + "state_key": "", + "type": "m.room.type", + "unsigned": { + "age": 1234 + } +} +``` + +### Filter API Changes + +``` +POST /_matrix/client/r0/user/%40alice%3Aexample.com/filter HTTP/1.1 +Content-Type: application/json + +{ + "room": { + "state": { + "types": [ + "m.room.*" + ], + "not_rooms": [ + "!726s6s6q:example.com" + ], + "room_types": [ + "m.room_type.messaging" + ], + "not_room_types": [ + "m.room_type.iot.*" + ], + }, + "event_format": "client", + "event_fields": [ + "type", + "content", + "sender" + ] +} +``` From 8942865aab0f187863fec5fb65e45befaf726bf6 Mon Sep 17 00:00:00 2001 From: Jonathan Frederickson Date: Wed, 28 Oct 2020 00:22:05 -0400 Subject: [PATCH 2/8] MSC1840: Remove 'room_type' from example room type keys Based on feedback in PR discussion; `room_type` is redundant given the context. --- proposals/1840-room-types.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/1840-room-types.md b/proposals/1840-room-types.md index 279e25df44e..1ba9e750ed1 100644 --- a/proposals/1840-room-types.md +++ b/proposals/1840-room-types.md @@ -39,7 +39,7 @@ this proposal at this point. ```json { "content": { - "type": "m.room_type.messaging" + "type": "m.messaging" }, "event_id": "$143273582443PhrSn:domain.com", "origin_server_ts": 1432735824653, From e68bdfbf6c129be2fc282cfe7672b5ca7529a545 Mon Sep 17 00:00:00 2001 From: Jonathan Frederickson Date: Wed, 28 Oct 2020 00:23:26 -0400 Subject: [PATCH 3/8] MSC1840: Change domain.com domains to example.com Just for cleanliness here, since domain.com is a real thing. --- proposals/1840-room-types.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/1840-room-types.md b/proposals/1840-room-types.md index 1ba9e750ed1..c8017cdb746 100644 --- a/proposals/1840-room-types.md +++ b/proposals/1840-room-types.md @@ -41,10 +41,10 @@ this proposal at this point. "content": { "type": "m.messaging" }, - "event_id": "$143273582443PhrSn:domain.com", + "event_id": "$143273582443PhrSn:example.com", "origin_server_ts": 1432735824653, - "room_id": "!jEsUZKDJdhlrceRyVU:domain.com", - "sender": "@example:domain.com", + "room_id": "!jEsUZKDJdhlrceRyVU:example.com", + "sender": "@user:example.com", "state_key": "", "type": "m.room.type", "unsigned": { From 896602a05e9d205352b005ad2def2eff9933f130 Mon Sep 17 00:00:00 2001 From: Jonathan Frederickson Date: Wed, 28 Oct 2020 00:24:42 -0400 Subject: [PATCH 4/8] MSC1840: Add example room types/use cases --- proposals/1840-room-types.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/proposals/1840-room-types.md b/proposals/1840-room-types.md index c8017cdb746..fa0adf79702 100644 --- a/proposals/1840-room-types.md +++ b/proposals/1840-room-types.md @@ -18,7 +18,19 @@ work around this limitation on a case-by-case basis. ## Solution The proposal is to add a new state event, `m.room.type`, to define the -intended usage of the room. +intended usage of the room. Some example use cases for this: + +- A long-form email-style client wants to provide a UI for sending + longer (possibly threaded) messages, but doesn't want those threads + to be overwhelmed by users sending short IM-style messages + (`m.messaging.mail` perhaps?) +- A blogging app built on Matrix wants to define and use custom "blog + post" and "comment" message types, but doesn't want Element users to + join with a client that doesn't understand any of the messages +- 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`) This by itself could be used by a client to properly display rooms based on their intended usage. However, to optimize the use of From f5543dc40b76fa0882d99b4b85b007b7f9751261 Mon Sep 17 00:00:00 2001 From: Jonathan Frederickson Date: Wed, 28 Oct 2020 00:27:02 -0400 Subject: [PATCH 5/8] MSC1840: Document grammar of acceptable values for 'type' --- proposals/1840-room-types.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/proposals/1840-room-types.md b/proposals/1840-room-types.md index fa0adf79702..99a99423696 100644 --- a/proposals/1840-room-types.md +++ b/proposals/1840-room-types.md @@ -32,6 +32,10 @@ intended usage of the room. Some example use cases for this: for this to clutter up the user's Element room list (`com.example.manufacturer.iot.light`) +The value of `type` must conform to +[MSC2758](https://github.com/matrix-org/matrix-doc/blob/master/proposals/2758-textual-id-grammar.md) +rules for textual identifiers. + This by itself could be used by a client to properly display rooms based on their intended usage. However, to optimize the use of bandwidth for an account used for varying purposes, the filter API From e1ab4382a01bbd4c6e077fe478478a7e6edd38b3 Mon Sep 17 00:00:00 2001 From: Jonathan Frederickson Date: Wed, 28 Oct 2020 00:27:53 -0400 Subject: [PATCH 6/8] MSC1840: Add note about default room type assumption 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. --- proposals/1840-room-types.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/proposals/1840-room-types.md b/proposals/1840-room-types.md index 99a99423696..371628e6b45 100644 --- a/proposals/1840-room-types.md +++ b/proposals/1840-room-types.md @@ -36,6 +36,13 @@ The value of `type` must conform to [MSC2758](https://github.com/matrix-org/matrix-doc/blob/master/proposals/2758-textual-id-grammar.md) rules for textual identifiers. +This proposal defines `m.messaging` as the (thus far) traditional +instant-messaging style room found in Element and most other Matrix +clients today. A room without an `m.room.type` state event may be +considered to be of type `m.messaging` for backwards-compatibility +reasons, but IM clients aware of room types should add an +`m.messaging` room type state event when creating a new room. + This by itself could be used by a client to properly display rooms based on their intended usage. However, to optimize the use of bandwidth for an account used for varying purposes, the filter API From 56ac6a15fb7c1db70bda32e29e9c7f3410fbd5fd Mon Sep 17 00:00:00 2001 From: Jonathan Frederickson Date: Wed, 28 Oct 2020 00:48:37 -0400 Subject: [PATCH 7/8] MSC1840: Clarify that `type` is user-extensible --- proposals/1840-room-types.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/1840-room-types.md b/proposals/1840-room-types.md index 371628e6b45..130353c041d 100644 --- a/proposals/1840-room-types.md +++ b/proposals/1840-room-types.md @@ -32,7 +32,9 @@ intended usage of the room. Some example use cases for this: for this to clutter up the user's Element room list (`com.example.manufacturer.iot.light`) -The value of `type` must conform to +The list of possible values of `type` is user-extensible; this +proposal defines `m.messaging`, but other types may be used by +client developers as desired. Grammar of values must conform to [MSC2758](https://github.com/matrix-org/matrix-doc/blob/master/proposals/2758-textual-id-grammar.md) rules for textual identifiers. From 4936ff4cbeb78e84e50d34c8e968ae9b06abb195 Mon Sep 17 00:00:00 2001 From: Jonathan Frederickson Date: Wed, 28 Oct 2020 01:23:03 -0400 Subject: [PATCH 8/8] MSC1840: Don't specify an explicit default for untyped rooms 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. --- proposals/1840-room-types.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/proposals/1840-room-types.md b/proposals/1840-room-types.md index 130353c041d..ca9bd626e0b 100644 --- a/proposals/1840-room-types.md +++ b/proposals/1840-room-types.md @@ -40,10 +40,12 @@ rules for textual identifiers. This proposal defines `m.messaging` as the (thus far) traditional instant-messaging style room found in Element and most other Matrix -clients today. A room without an `m.room.type` state event may be -considered to be of type `m.messaging` for backwards-compatibility -reasons, but IM clients aware of room types should add an -`m.messaging` room type state event when creating a new room. +clients today. Client developers may handle rooms without a type in a +way that makes sense for each client; for example, it is expected that +an IM client would list both untyped rooms (for backwards +compatibility) and rooms of type `m.messaging` in the room +list. However, clients that are aware of room types should add the +relevant room type state event when creating new rooms. This by itself could be used by a client to properly display rooms based on their intended usage. However, to optimize the use of