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
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.
invite_room_state
andknock_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
orunsigned.knock_room_state
field respectively. This allows us to easily pass these events around - specifically to the sync code, where they are extracted intoinvite_state
andknock_state
fields for the recipient user, and application service code, where they are supposed to be included inunsigned.invite_room_state
andunsigned.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:
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
The text was updated successfully, but these errors were encountered: