Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

We should stop putting invite_room_state and knock_room_state into the unsigned field of events #14160

Open
anoadragon453 opened this issue Oct 12, 2022 · 0 comments
Labels
A-Invite Inviting users to rooms and accepting invites O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.

Comments

@anoadragon453
Copy link
Member

anoadragon453 commented Oct 12, 2022

invite_room_state and knock_room_state are both an array of events that contain some room prejoin state - stripped state events which are given to a user when they are invited to a room, or knock on a room.

Today in Synapse we attach these events to the user's invite or knock membership event, in an unsigned.invite_room_state or unsigned.knock_room_state field respectively. This allows us to easily pass these events around - specifically to the sync code, where they are extracted into invite_state and knock_state fields for the recipient user, and application service code, where they are supposed to be included in unsigned.invite_room_state and unsigned.knock_room_state.

They shouldn't be appearing anywhere else though, yet attaching them to the event in the database can end up with us missing a spot where we forget to remove it (such as #14064).

I think a better solution would be to not store this field in the event at all. Instead, we should either:

  • generate the stripped state events when needed, or
  • store them in a separate database table and only pull from them when needed.

The latter has the advantage of being able to quickly pull the state at the point in the room when the invite/knock was generated. Though I don't think the spec actually mandates that the stripped state be the state of the room at the membership event...

There's also the question of removing the fields from past events before we remove any of the code that strips these fields before sending them to clients.

Related: matrix-org/matrix-spec#1273

@anoadragon453 anoadragon453 added S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. A-Invite Inviting users to rooms and accepting invites O-Uncommon Most users are unlikely to come across this or unexpected workflow labels Oct 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Invite Inviting users to rooms and accepting invites O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Tolerable Minor significance, cosmetic issues, low or no impact to users. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.
Projects
None yet
Development

No branches or pull requests

1 participant