Skip to content

Commit 4b7dc17

Browse files
committed
Include an API endpoint.
1 parent 6923606 commit 4b7dc17

File tree

1 file changed

+94
-17
lines changed

1 file changed

+94
-17
lines changed

proposals/3173-expose-stripped-state-events.md

Lines changed: 94 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,11 @@
11
# MSC3173: Expose stripped state events to any potential joiner
22

3-
The current design of Matrix somtimes allows for inspecting part of the room state
4-
without being joined to the room:
3+
It can be useful to view the partial state of a room before joining to allow a user
4+
to know *what* they're joining. For example, it improves the user experience to
5+
show the user the room name and avatar before joining.
6+
7+
It is already allowed to partially view the room state without being joined to
8+
the room in some situations:
59

610
* If the room has `history_visibility: world_readable`, then anyone can inspect
711
it (by calling `/state` on it).
@@ -14,7 +18,13 @@ without being joined to the room:
1418
This MSC proposes allowing the stripped state events that are currently available
1519
to invited and knocking users to any user who could potentially join a room. It
1620
also consolidates the recommendation on which events to include as stripped state
17-
for potential joiners.
21+
for potential joiners and provides a way to query for the stripped state directly.
22+
23+
This will allow for improved future use cases, such as:
24+
25+
* Improved user experience for more complicated access controls (e.g.
26+
[MSC3083](https://github.com/matrix-org/matrix-doc/pull/3083)).
27+
* More information available to platforms like matrix.to.
1828

1929
## Background
2030

@@ -64,16 +74,18 @@ recommends including the `m.room.create` event as one of the stripped state even
6474
6575
## Proposal
6676

67-
This proposal includes two aspects which are dealt with separately:
77+
This proposal includes a few aspects which are dealt with separately:
6878

6979
1. Generalizing when a user is allowed to view the stripped state of a room.
7080
2. A consistent recommendation for which events to include in the stripped state.
81+
3. Providing a dedicated API for accessing the stripped state of the room.
7182

7283
### Accessing the stripped state of a room
7384

7485
Any user who is able to join a room shall be allowed to have access the stripped
75-
state events of that room. No changes are proposed to the mechanics of how the
76-
users may get those state events.
86+
state events of that room. Additionally, any user who could access the state of
87+
a room may access the stripped state of a room, as it is a strict subset of
88+
information.
7789

7890
Potential ways that a user might be able to join a room include, but are not
7991
limited to, the following mechanisms:
@@ -103,6 +115,67 @@ following as stripped state events:
103115
* Encryption information (`m.room.encryption`)<sup id="a2">[2](#f2)</sup>
104116
* Room topic (`m.room.topic`)<sup id="a3">[3](#f3)</sup>
105117

118+
### Stripped state API
119+
120+
`GET /_matrix/client/r0/rooms/{roomId}/stripped_state`
121+
122+
A dedicated API is provided to query for the stripped state of a room. As
123+
described above, any potential joiner may access the stripped state of a room
124+
(and in the case of a room with `history_visibility: world_readable` -- anyone
125+
may access the stripped state, as it is a strict subset of the state).
126+
127+
This API is rate-limited and does not require authentication.
128+
129+
The request format follows [the `/state`](https://matrix.org/docs/spec/client_server/latest#get-matrix-client-r0-rooms-roomid-state)
130+
endpoint.
131+
132+
The response body includes an array of `StrippedState`, as
133+
[described in the `/sync` response](https://matrix.org/docs/spec/client_server/latest#get-matrix-client-r0-sync).
134+
135+
#### Example request:
136+
137+
`GET /_matrix/client/r0/rooms/%21636q39766251%3Aexample.com/stripped_state HTTP/1.1`
138+
139+
#### Responses:
140+
141+
##### Status code 200:
142+
143+
The current stripped state of the room
144+
145+
```json
146+
[
147+
{
148+
"content": {
149+
"join_rule": "public"
150+
},
151+
"type": "m.room.join_rules",
152+
"sender": "@example:example.org",
153+
"state_key": ""
154+
},
155+
{
156+
"content": {
157+
"creator": "@example:example.org",
158+
"room_version": "1",
159+
"m.federate": true,
160+
"predecessor": {
161+
"event_id": "$something:example.org",
162+
"room_id": "!oldroom:example.org"
163+
}
164+
},
165+
"type": "m.room.create",
166+
"sender": "@example:example.org",
167+
"state_key": ""
168+
}
169+
]
170+
```
171+
172+
Note that this is the same example as [the `/state` endpoint](https://matrix.org/docs/spec/client_server/latest#get-matrix-client-r0-rooms-roomid-state),
173+
but limited to what would be returned as stripped state.
174+
175+
##### Status code 403:
176+
177+
You are not a member of the room, a potential joiner, and the room is not publicly viewable.
178+
106179
## Potential issues
107180

108181
This is a generalization of current behavior and shouldn't introduce any new issues.
@@ -115,25 +188,29 @@ knocking.
115188

116189
## Security considerations
117190

118-
This would allow for invisibly accessing the stripped state of a room with `knock`
119-
join rules. This is already trivially accessible by knocking on the room, but
120-
currently users in the room would know that the knock occurred. This does not
121-
seem to be a major weakening of the security.
191+
This would allow for invisibly accessing the stripped state of a room with `public`
192+
or `knock` join rules.
122193

123-
## Future extensions
194+
In the case of a public room, if the room has `history_visibility` set to `world_readable`
195+
then this is no change. Otherwise, it is trivial to access the state of the room
196+
by joining, but currently users in the room would know that the join occurred.
197+
Additionally, this information is already provided by the room directory (if
198+
the room is listed there).
124199

125-
### Dedicated APIs
200+
Similarly, in the case of knocking, a user is able to trivially access the
201+
stripped state of the room by knocking, but users in the room would know that
202+
the knock occurred.
126203

127-
Dedicated client-server and server-server APIs could be added to request the
128-
stripped state events, but that is considered out-of-scope for the current
129-
proposal.
204+
This does not seem to be weakening the security expectations of either join rule.
205+
206+
## Future extensions
130207

131208
### Revisions to the room directory
132209

133210
A future MSC could include additional information from the stripped state events
134211
in the [room directory](https://matrix.org/docs/spec/client_server/latest#get-matrix-client-r0-publicrooms).
135-
This seems to mostly be the encryption information, but there may also be other
136-
pieces of information to include.
212+
The main missing piece seems to be the encryption information, but there may also
213+
be other pieces of information to include.
137214

138215
### Additional ways to join a room
139216

0 commit comments

Comments
 (0)