Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meaning of RoomFilter with omitted account_data, ephemeral, state or timeline fields is unclear #1219

Open
DMRobertson opened this issue Aug 30, 2022 · 1 comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@DMRobertson
Copy link
Contributor

Link to problem area: https://spec.matrix.org/v1.3/client-server-api/#post_matrixclientv3useruseridfilter, definition of RoomFilter

Issue

rooms says:

Name Type Description
rooms [string] A list of room IDs to include. If this list is absent then all rooms are included. This filter is applied before the filters in ephemeral, state, timeline or account_data

(emphasis mine).

The other fields do not describe the meaning of the filter if they are omitted.

Name Type Description
account_data RoomEventFilter The per user account data to include for rooms.
ephemeral RoomEventFilter The events that aren’t recorded in the room history, e.g. typing and receipts, to include for rooms.
state StateFilter The state events to include for rooms.
timeline RoomEventFilter The message and state update events to include for rooms.

Noticed in matrix-org/synapse#13648

@DMRobertson DMRobertson added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Aug 30, 2022
@Benjamin-L
Copy link

All of the individual fields on {RoomEvent,State}Filter are optional, and the spec does describe their semantics when each field is omitted. I believe omitting any of these filters is equivalent to passing {} ({RoomEvent,State}Filter with all fields omitted). This is the behavior implemented by ruma's type definition (the #[serde(default...)] annotations cause it to deserialize json with that field missing using the default value for the field's type).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
Development

No branches or pull requests

2 participants