|
| 1 | +- **Author**: Jonathan Frederickson |
| 2 | +- **Created**: 2019-02-03 |
| 3 | + |
| 4 | +# Room Types |
| 5 | + |
| 6 | +## Problem |
| 7 | + |
| 8 | +The Matrix protocol currently has no mechanism to differentiate rooms |
| 9 | +from each other based on their intended use case. There have been |
| 10 | +proposals such as |
| 11 | +[MSC1769](https://github.com/matrix-org/matrix-doc/pull/1769) and |
| 12 | +[MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) that use |
| 13 | +rooms for purposes other than the traditional messaging |
| 14 | +use-case. Without a mechanism to differentiate them from messaging |
| 15 | +rooms, clients will display them as they do any other room unless they |
| 16 | +work around this limitation on a case-by-case basis. |
| 17 | + |
| 18 | +## Solution |
| 19 | + |
| 20 | +The proposal is to add a new state event, `m.room.type`, to define the |
| 21 | +intended usage of the room. |
| 22 | + |
| 23 | +This by itself could be used by a client to properly display rooms |
| 24 | +based on their intended usage. However, to optimize the use of |
| 25 | +bandwidth for an account used for varying purposes, the filter API |
| 26 | +could then be extended to allow for filtering the rooms that are |
| 27 | +returned from a sync based on room type. (A client meant for receiving |
| 28 | +IoT device data, for example, has no need to receive messages destined |
| 29 | +for that account, nor to be aware at all that messaging rooms exist.) |
| 30 | + |
| 31 | +N.B. There's an opportunity here to additionally scope access tokens |
| 32 | +to specific room types, but that feels like it's beyond the scope of |
| 33 | +this proposal at this point. |
| 34 | + |
| 35 | +## Examples |
| 36 | + |
| 37 | +### m.room.type |
| 38 | + |
| 39 | +```json |
| 40 | +{ |
| 41 | + "content": { |
| 42 | + "type": "m.room_type.messaging" |
| 43 | + }, |
| 44 | + "event_id": "$143273582443PhrSn:domain.com", |
| 45 | + "origin_server_ts": 1432735824653, |
| 46 | + "room_id": "!jEsUZKDJdhlrceRyVU:domain.com", |
| 47 | + "sender": "@example:domain.com", |
| 48 | + "state_key": "", |
| 49 | + "type": "m.room.type", |
| 50 | + "unsigned": { |
| 51 | + "age": 1234 |
| 52 | + } |
| 53 | +} |
| 54 | +``` |
| 55 | + |
| 56 | +### Filter API Changes |
| 57 | + |
| 58 | +``` |
| 59 | +POST /_matrix/client/r0/user/%40alice%3Aexample.com/filter HTTP/1.1 |
| 60 | +Content-Type: application/json |
| 61 | +
|
| 62 | +{ |
| 63 | + "room": { |
| 64 | + "state": { |
| 65 | + "types": [ |
| 66 | + "m.room.*" |
| 67 | + ], |
| 68 | + "not_rooms": [ |
| 69 | + "!726s6s6q:example.com" |
| 70 | + ], |
| 71 | + "room_types": [ |
| 72 | + "m.room_type.messaging" |
| 73 | + ], |
| 74 | + "not_room_types": [ |
| 75 | + "m.room_type.iot.*" |
| 76 | + ], |
| 77 | + }, |
| 78 | + "event_format": "client", |
| 79 | + "event_fields": [ |
| 80 | + "type", |
| 81 | + "content", |
| 82 | + "sender" |
| 83 | + ] |
| 84 | +} |
| 85 | +``` |
0 commit comments