Spec does not specify how to handle duplicate auth events

[richvdh]

Suppose you receive an event over federation whose auth_events include two m.room.member events for the sender. One of those events is a join, and one is a leave. Should we accept the event or not?

I think the answer is probably "if the auth_events specify multiple events with the same (type, state_key), the event should be rejected", but the spec doesn't say that, and it's not what Synapse currently does.

[richvdh]

this is probably part of https://github.com/matrix-org/matrix-doc/issues/1646

[erikjohnston]

I'm sure we've talked in the past that we might want to enforce that the auth_events field should only include event types that are expected, I think maybe as part of our work in reducing sizes of events or something? I'm failing to find it though, so I'm more mentioning this in the hopes it jogs someone else's memory...

[richvdh]

I think the answer is probably "if the auth_events specify multiple events with the same (type, state_key), the event should be rejected", but the spec doesn't say that, and it's not what Synapse currently does.

This is incorrect; the spec says exactly that and has done since matrix-org/matrix-spec-proposals#1594. From https://spec.matrix.org/v1.2/rooms/v9/#authorization-rules:

2. Reject if event has auth_events that:
   1. have duplicate entries for a given type and state_key pair
   2. have entries whose type and state_key don’t match those specified by the auth events selection algorithm described in the server specification.