From 1c34a466edc7b675339cbf984e18399cbb5ff01e Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 17 May 2021 11:30:26 -0400 Subject: [PATCH] Various clarifications based on feedback. --- .../3173-expose-stripped-state-events.md | 51 +++++++++++++------ 1 file changed, 36 insertions(+), 15 deletions(-) diff --git a/proposals/3173-expose-stripped-state-events.md b/proposals/3173-expose-stripped-state-events.md index b80f6256..ac88305b 100644 --- a/proposals/3173-expose-stripped-state-events.md +++ b/proposals/3173-expose-stripped-state-events.md @@ -1,15 +1,17 @@ # MSC3173: Expose stripped state events to any potential joiner -It is currently possible to inspect the state of rooms in some circumstances: +The current design of Matrix somtimes allows for inspecting part of the room state +without being joined to the room: * If the room has `history_visibility: world_readable`, then anyone can inspect it (by calling `/state` on it). -* Rooms in the room directory expose some of their state publicly. +* Rooms in the [room directory](https://matrix.org/docs/spec/client_server/latest#get-matrix-client-r0-publicrooms) + expose some of their state publicly. * [Invited users](https://matrix.org/docs/spec/server_server/r0.1.4#put-matrix-federation-v2-invite-roomid-eventid) - (and [knocking users](https://github.com/matrix-org/matrix-doc/pull/2403)) - receive stripped state events. + and [knocking users](https://github.com/matrix-org/matrix-doc/pull/2403) + receive stripped state events to display metadata to users. -This MSC proposes exposing the stripped state events that are currently available +This MSC proposes allowing the stripped state events that are currently available to invited and knocking users to any user who could potentially join a room. It also consolidates the recommendation on which states events are available to potential joiners. @@ -62,10 +64,13 @@ recommends including the `m.room.create` event as one of the stripped state even ## Proposal -Any user who is able to join a room can access the stripped state events of that room. +Any user who is able to join a room shall be allowed to have access the stripped +state events of that room. No changes are proposed to the mechanics of how the +users may get those state events, e.g. the `invite_state` of an invite or the +roomd irectory. -Potential ways that a user might be able to join include, but are not limited to, -the following mechanisms: +Potential ways that a user might be able to join a room include, but are not +limited to, the following mechanisms: * A room that has `join_rules` set to `public` or `knock`. * A room that the user is in possession of an invite to (regardless of the `join_rules`). @@ -77,8 +82,10 @@ should consider this MSC, for example: proposes allowing users to join a room based on their membership in a space (as defined in [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772)). -Additionally, it is recommended, but not required, that homeserver implementations -include the following as stripped state events: +It is also proposed to create a single definition for what stripped state events +should be provided to be potential joiners. Thus, it is recommended (although not +required[0](#f0)) that homeserver implementations include the +following as stripped state events: * Create event (`m.room.create`)[1](#f1) * Join rules (`m.room.join_rules`) @@ -88,11 +95,6 @@ include the following as stripped state events: * Encryption information (`m.room.encryption`)[2](#f2) * Room topic (`m.room.topic`)[3](#f3) -This also implies that the above information is available to any potential joiner -in the API proposed in [MSC2946: Spaces summary](https://github.com/matrix-org/matrix-doc/pull/2946). -E.g. rooms which could be joined due to [MSC3083](https://github.com/matrix-org/matrix-doc/pull/3083) -can expose the information available in stripped state events. - ## Potential issues This is a generalization of current behavior and shouldn't introduce any new issues. @@ -112,16 +114,35 @@ seem to be a major weakening of the security. ## Future extensions +### Dedicated APIs + Dedicated client-server and server-server APIs could be added to request the stripped state events, but that is considered out-of-scope for the current proposal. +### Revisions to the room directory + +A future MSC could include additional information from the stripped state events +in the [room directory](https://matrix.org/docs/spec/client_server/latest#get-matrix-client-r0-publicrooms). +This seems to mostly be the encryption information, but there may also be other +pieces of information to include. + +### Additional ways to join a room + +[MSC3083](https://github.com/matrix-org/matrix-doc/pull/3083) leverages this to +expose the information available in stripped state events via the spaces summary +for potential joiners due to membership in a space. + ## Unstable prefix N/A ## Footnotes +[0]: Privacy conscious deployments may wish to limit the metadata +available to users who are not in a room as the trade-off against user experience. +There seems to be no reason to not allow this. [↩](#a0) + [1]: As updated in [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772). [↩](#a1) [2]: The encryption information (`m.room.encryption`) is already sent