mirror of
https://github.com/element-hq/synapse.git
synced 2026-11-04 13:28:04 +00:00
Kegan DougalandClaude Fable 5.1
6e7672f595
What a client sees of a member key room: every event names a member key as its sender and, through MSC4428, as its stable ID; `member_info` resolves the keys to users; the requester is recognised by their key wherever the server decides what they may see or which events are theirs; and `/members` and `/joined_members` are keyed by key. One homeserver only, but the code answers for members of other servers too (a verified link names the user it claims, anything else is nobody). `member_info`. MSC4428's map, which only named erased users (the stable ID of an ordinary room is the user ID and the entry is omitted), now gives every member key an entry: the user behind a key we hold, the user named by a verified link for another server's key, and `null` for an erased user or a key nobody vouches for (an unverified claim is anyone's to make). The resolution is one batched store lookup (`get_user_ids_for_identities`, exposed by the member key handler as `user_ids_for_identities`), so the map costs rooms without member keys nothing. The map already covers `/sync` (full and incremental), sliding sync, `/members` and `/joined_members`, which are keyed by state key and so by key; nothing there changes. An erasure is recorded on the change stream under the stable ID that changed, which in these rooms is the member's key, so the entry that flips to `null` is the one clients hold. Visibility. `filter_and_transform_events_for_client` decided what the requester may see from their membership under their user ID, which the state of a member key room does not hold: a joined user saw nothing. It now looks the requester up under their key in each member key room the batch touches, for both the allow check and the membership the event is annotated with, and maps senders back to users, per room (a key is only a user in the room it was looked up in), for the two per-user checks: erased senders, whose events are pruned for users who joined later, so a key with no attributable user is not erased; and ignored senders, where a member may be ignored as the user behind their key or as the key itself, since a key with no attributable user is the only handle a client has on it. `filter_event_for_clients_with_state`, which push evaluation uses to decide who may see an event, does the same per local user, for the ignore lists as for the memberships, including for the out-of-band membership events it returns to their target. The push evaluator itself resolves the sender (so a user is not notified of their own events), the invitee and the inviter (so an invite notifies its target, and the invitee's invite rules see the inviter as a user, where one is attributable). The requester's own events. The serializer echoes `transaction_id` and `delay_id` only to the sender's own session, by comparing the sender with the requester's user ID, which in a member key room never matches. `SerializeEventConfig.requester_member_keys` (a new keyword-only argument, `None` by default, so existing constructions are unchanged) carries the requester's keys and the Rust serializer accepts a sender among them; `create_config` fills it from the cached per-user keys when the feature is on. Keys are unique across rooms, so a key of the requester's can only ever be their own sender. Sync. Where the handlers compared the requester's user ID with a sender or a membership state key, they now use the identity the room knows them by (`room_identity_for_user`: their key where they have one, their user ID otherwise, or the cached map of their keys per room): the incremental sync reads the requester's previous membership under their key, so a change to their own membership (a display name) is an ordinary timeline event rather than the room sent again as newly joined, and a leave is newly left; the heroes of a nameless room no longer include the requester; the lazy-loading full sync fetches the requester's own membership under their key; a leave the user sent themselves is told from a kick by their keys per room, in sync and in the sliding sync room lists; the join-race guard asks the user-keyed membership table; and sliding sync's `$ME` is the requester's key, including in the computation of which required state has changed between requests. An invite's sender is resolved to a user (where attributable) for the ignore list and the invite rules, in sync and in both sliding sync room lists: a key on the ignore list hides the invite too, and an unattributable key no longer reaches the invite rules, which parse user IDs and would have failed the whole sync. The members handed to presence and to device lists, by sync, by the device handler for newly joined and left rooms, and by the room initial sync, are mapped to users first, so clients are told about users' devices and presence, not keys'. The three storage queries that find a user's membership changes in `current_state_delta_stream` and `room_memberships` share one clause that, with the feature on, also matches the keys we hold for the user, each scoped to its room (keys are public strings anyone can name as a state key elsewhere) and spelled out from the cached per-user keys so that every arm of the clause can use the tables' indexes; a user with no keys, and the feature being off, get the legacy clause byte for byte. Sliding sync's "newly joined" and "newly left" detection, and the device handler's shared-room tracking, run on those queries. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>