-
Couldn't load subscription status.
- Fork 414
MSC4319: Room member events in stripped state #4319
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
base: main
Are you sure you want to change the base?
MSC4319: Room member events in stripped state #4319
Conversation
Signed-off-by: Kévin Commaille <[email protected]>
Signed-off-by: Kévin Commaille <[email protected]>
Signed-off-by: Kévin Commaille <[email protected]>
Signed-off-by: Kévin Commaille <[email protected]>
| display information about the sender of an invite, like their display name or avatar. | ||
|
|
||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clients have depended on synapse's behaviour of including the full client formatted event for the m.room.member invite event.
the-draupnir-project/Draupnir#945
In draupnir this dependency is more than just a parsing issue. The matrix-protection-suite provides a handle called handleExternalMembership which invitations are fed into from the matrix-protection-suite's conception of the timeline, which is closer to appservice push than /sync. As appservice push also pushed invitations this way.
Deduplication and buffering is then coordinated using the event id as it is identical to any other client formatted event and not special cased. So this is a deep dependency.
https://github.com/Gnuxie/matrix-protection-suite/blob/a85102c0aaa6ba73beae8fdb35600eec0999eada/src/Protection/Protection.ts#L176
https://github.com/the-draupnir-project/Draupnir/blob/main/src/protections/invitation/JoinRoomsOnInviteProtection.tsx#L86-L96
https://github.com/the-draupnir-project/Draupnir/blob/f1dad52288ff32a096cbd3ff5be110648574c51f/src/Draupnir.ts#L355
https://github.com/Gnuxie/matrix-protection-suite/blob/453e55b182282aad59db430f53549d89541a8e21/src/ClientManagement/StandardClientRooms.ts#L95-L126
https://github.com/the-draupnir-project/Draupnir/blob/f1dad52288ff32a096cbd3ff5be110648574c51f/src/DraupnirBotMode.ts#L97-L99
https://github.com/the-draupnir-project/Draupnir/blob/f1dad52288ff32a096cbd3ff5be110648574c51f/src/appservice/AppService.ts#L355
| display information about the sender of an invite, like their display name or avatar. | ||
|
|
||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change complicates clients that allow either /sync or appservice push to be their event source. Since now invitations sourced from /sync will be a different format to those provided in appservice push. See #4319 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally, the appservice event can't be stripped, because then you'd have two different data formats in the events array of /transactions
In this specific context, the AS API is closer to S-S than C-S /sync, as both AS and S-S send full invite events with stripped state in unsigned -> invite_room_state, while /sync flattens invite event + stripped state into an invite_state array
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have changed the proposal in 1b81df4 to send the full event in a different place to attempt to take care of two concerns at once: the event formats should not be mixed in invite_state, and implementations rely on all fields of the full event format.
Signed-off-by: Kévin Commaille <[email protected]>
This was spawned by the discussion in matrix-org/matrix-spec#2181.
Server Implementations:
m.room.memberininvite_state: https://github.com/element-hq/synapse/blob/458e6410e8388fbc6b60b5575850405939bc53eb/synapse/rest/client/sync.py#L450-L462m.room.memberininvite_state: https://github.com/element-hq/synapse/blob/a6e326582f735e03e420c3b86475388fb5f2656c/synapse/handlers/message.py#L1835-L1839m.room.memberinknock_state: https://github.com/element-hq/synapse/blob/458e6410e8388fbc6b60b5575850405939bc53eb/synapse/rest/client/sync.py#L486-L514m.room.memberininvite_state: https://github.com/element-hq/dendrite/blob/8d2da78744387e55c28bb8925ae0cc70dd3e02e3/syncapi/types/types.go#L530-L574invite_state.knock_state.m.room.memberininvite_state(common to all forks): https://gitlab.com/famedly/conduit/-/blob/ed5b0514f52f848e53785dee5fe8de63780cf092/src/api/server_server.rs#L2160-2172m.room.memberininvite_state(Conduit): https://gitlab.com/famedly/conduit/-/merge_requests/766m.room.memberinknock_state(Conduit): https://gitlab.com/famedly/conduit/-/blob/ed5b0514f52f848e53785dee5fe8de63780cf092/src/api/server_server.rs#L2160-2172Most clients already rely on being able to access the
m.room.memberevents of the knock or invite process, and of the inviter.The following client implementations also rely on being able to access the
origin_server_ts:StrippedStateand add optional fields toStrippedStateEventinstead ruma/ruma#2187Rendered