Confusing cycle: S-S API -> room version auth rules -> S-S api auth events selection

[DMRobertson]

To find out what checks need to be made of incoming PDUs, one must consult the server-server API. For checking the auth_events in particular, we learn here that tells you that the rules depend on the room version.

Each individual room version has the following as step 2:

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.

Following that link takes you back to the server-server API. I found that confusing. Then for steps 3 onward you switch back to the room version document.

It might be clearer to make the auth event selection rules part of the room version itself---particularly if we might want to change those rules in the future?

[DMRobertson]

To further add to the confusion: if you want to look up the event-specific structure of an incoming PDU's content, you probably have to consult the client-server API.

This is frustrating: it means the definition of Matrix's underlying data model is distributed across three different sections of the spec.