mirror of
https://github.com/element-hq/synapse.git
synced 2026-11-05 11:08:00 +00:00
Kegan DougalandClaude Opus 5
cc2477541c
A membership event carries the claim about who its member key belongs to, and a join that makes no claim leaves its sender attributable to nobody: not routable, not shown to clients, soft failed by every server that receives anything further from them. The joins this server sent to member key rooms made no claim. The gap was in where the linkage information is filled in. For events a client asks us to create, that happens while the event dict is being translated into member keys, which is also where a client's own attempt to assert linkage information is thrown away. A join sent over federation never goes through that path: the template comes from the resident server, we fill in the client's content and sign it, and nothing along the way says who we are. So fill it in there too, once the room version coming back from `/make_join` shows the room wants it: our domain, and the user's localpart unless they are erased, in which case their name is not published again. Whatever the client asked for is dropped first, as it is everywhere else — a client may not say who a member key belongs to, only the server holding it may. The event is then signed by the member key and co-signed by us, which is what makes the claim worth anything to the server receiving it. Also stop recording a link against a member key this server holds. Links describe other servers' keys, and for our own we already know the answer, so the row would be at best redundant. It becomes actively wrong once a member key is moved between servers: the new server's claim about it is still not ours to write down against our own copy. The tests drive the outbound half with a stubbed resident server, so what we put on the wire is checked rather than assumed. The tests for the inbound half build their events by hand and so never exercised this. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>