Skip to content
Open
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions proposals/4319-non-stripped-member-in-stripped-state.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
# MSC4139: Non-stripped room member event in stripped state

In the Client-Server API, the response of the [`GET /sync`](https://spec.matrix.org/v1.15/client-server-api/#get_matrixclientv3sync)
endpoint, the `events` array in the `invite_state` for rooms under `invite` and in the `knock_state`
for rooms under `knock` are defined as containing the stripped state of the room.

This stripped state comes over federation, via the
[`PUT /invite`](https://spec.matrix.org/v1.15/server-server-api/#put_matrixfederationv2inviteroomideventid)
and [`PUT /send_knock`](https://spec.matrix.org/v1.15/server-server-api/#put_matrixfederationv1send_knockroomideventid)
endpoints in the Server-Server API.

In the definition of the [stripped state](https://spec.matrix.org/v1.15/client-server-api/#stripped-state)
it is recommended to contain the following state events:

- `m.room.create`
- `m.room.name`
- `m.room.avatar`
- `m.room.topic`
- `m.room.join_rules`
- `m.room.canonical_alias`
- `m.room.encryption`

Although these events are useful to be able to present information about the room, they don't
contain information about the event itself, like the sender of the invite, or when it occurred.

_Note that this specifies behavior that has been implemented for a long time in homeserver
implementations and that clients already rely on._

## Proposal

The `m.room.member` event that was created during the invite or knock process MUST be present in
the `events` of the `invite_state` or `knock_state`. Since servers have access to the whole event,
and for clients to be able to access the time of the event via the `origin_server_ts` field, it
MUST use the same format as can be found in the `events` of `timeline` and `state` for rooms under
`join`. This is the format currently defined as
[`ClientEventWithoutRoomID`](https://spec.matrix.org/v1.15/client-server-api/#get_matrixclientv3sync_response-200_clienteventwithoutroomid).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, because clients want access to the origin_server_ts and generally speaking we don't want different formats for data in a list, this MSC could do two things:

  1. Add origin_server_ts to all stripped state events
  2. Add the inviting m.room.member event to the list of suggested state

Copy link
Contributor Author

@zecakeh zecakeh Aug 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also found a use case for accessing unsigned of an invite m.room.member event, for clients to be able to know if the invite is after a knock by looking into the prev_content.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not seeing why that would be important to them, or why that needs to come from unsigned instead of somewhere else

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To auto-accept an invite following a knock for example. If it's a new device there is no other place where this information can be found.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the stripped state event format to include origin_server_ts and unsigned (since this one is already optional in other event formats anyway).


_Note that the example for the response of `GET /sync` already include the stripped `m.room.member`
event although it is not specified._

Furthermore, clients need to be able to display information about the sender of an invite, like
their display name or avatar. The list of events that should be included in the stripped state is
extended with the stripped `m.room.member` event of the `sender` of the invite.

## Potential issues

By showing more information about the sender of an invite, users might be subject to undesirable
content like abusive language or images. Mitigating this is out of scope of this MSC, and other MSCs
exist for this, like [MSC4278](https://github.com/matrix-org/matrix-spec-proposals/pull/4278).


## Alternatives

No relevant alternatives.


## Security considerations

No potential security issues are known to the author.


## Unstable prefix

None necessary, this is adding existing event types into existing arrays.


## Dependencies

None.