Auth rules are unclear about which checks apply to auth events and which to room state

[richvdh]

Per https://spec.matrix.org/v1.3/server-server-api/#checks-performed-on-receipt-of-a-pdu, we check the auth rules three times for each event, based on different subsets of state:

• based on the event’s auth events
• based on the state before the event
• based on the current state of the room

However, some of the auth rules always apply to the auth events, and some are completely independent of any room state input. In particular, per https://spec.matrix.org/v1.3/rooms/v10/#authorization-rules:

• Rule 1 ("If type is m.room.create:") is completely independent of the room state.
• Rule 2 ("Reject if event has auth_events that:") and rule 3 ("If event does not have a m.room.create in its auth_events, reject.") always look at the auth events, never the room state.
• Rule 4 ("If the create event content has the field m.federate set to false...") is unclear, but since there should be only one create event in a room which is constant throughout the tests, we can consider it as always looking at the auth events.

The rest of the rules are intended to apply based on the room state based on the three different state sets mentioned above - but do not say as much.

This is somewhat confusing for the reader, but also makes a faithful implementation rather inefficient, because if we implement it literally we'll check the first four rules three times for exactly the same input.

I've recently (matrix-org/synapse#13065) split the two sets of checks into two functions in Synapse, and rather wonder if we should do the same in the spec.

[richvdh]

Rule 4 ("If the create event content has the field m.federate set to false...") is unclear, but since there should be only one create event in a room which is constant throughout the tests, we can consider it as always looking at the auth events.

I've attempted to clarify this in #1137, ftr