Skip to content

MSC4497: Filter state events by type in /state endpoint#4497

Open
pernydev wants to merge 3 commits into
matrix-org:mainfrom
pernydev:main
Open

MSC4497: Filter state events by type in /state endpoint#4497
pernydev wants to merge 3 commits into
matrix-org:mainfrom
pernydev:main

Conversation

@pernydev

@pernydev pernydev commented Jun 27, 2026

Copy link
Copy Markdown

Rendered

Signed-off-by: Perny hey@perny.dev

@pernydev pernydev changed the title Filter state events by type in /state endpoint MSC4497: Filter state events by type in /state endpoint Jun 27, 2026
@pernydev pernydev marked this pull request as ready for review June 27, 2026 03:19
@turt2live turt2live added proposal A matrix spec change proposal. Process state. A-Client Server Client-Server API kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Jun 29, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Implementation requirements:

  • Client (using)
  • Server (serving)

@pernydev pernydev Jun 29, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Will a reverse proxy based server implementation suffice for this MSC? I am personally not very familiar with the codebase of any major server implementation, so contributing to them would be difficult.

The limitation proxy would have here is the loss of the database efficiency angle, since a homeserver would need to still load all states.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Implementations don't need to be done by the MSC author. For an MSC like this we're primarily looking for evidence that a use case exists and that this MSC fulfills that. This ideally means that multiple clients require support for the feature, and at least one adds support for it. A proper server implementation would be best to demonstrate that the solution is desirable to the ecosystem.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Consider it done element-hq/synapse#19899

@turt2live turt2live left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This review is for early requirements gathering - it's not a review of the MSC itself.

Comment thread proposals/4497-state-event-type-filter.md
Comment thread proposals/4497-state-event-type-filter.md Outdated
Comment on lines +73 to +77
### Accept a full StateFilter

Instead of just `types`, the endpoint could accept a full `StateFilter` object (with `types`,
`not_types`, `senders`, `not_senders`, etc.). However, for most usecases `StateFilter` provides
a lot more than what is needed to read state.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Given that we already have RoomEventFilter established on /sync and /messages, I wonder if reusing it wouldn't be the cleaner design? It has no required fields. So even though it involves significantly more options than the single query parameter, clients wouldn't be forced to use all of them. Servers should also already have support for it, which should simplify the implementation.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Yeah that is true and something I thought of while writing this. I'd love to hear what people think about the usefulness of RoomEventFilter for state, it's a conversation worth having here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Client Server Client-Server API kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal. Process state.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants