v11 auth rules 2.2 is unclear in combination with auth event selection algo

[dkasak]

Link to problem area

• Auth rules 2.2
• Auth event selection algorithm

Issue

2.2 of the auth rules says:

If there are entries whose type and state_key don’t match those specified by the auth events selection algorithm described in the server specification, reject.

At the same time, the selection algorithm uses wording like "current [event of type T], if any".

Combining the two, I reason in the following way. Suppose I receive an event E, such that:

1. For some event A, E.prev_events = [A].
2. state_at(A) includes a PL event (or join rules, or sender/target membership events, etc).
3. E.auth_events does NOT include that PL event (or join rules, or sender/target membership events, etc).

First of all, what is the meaning of "current" in the selection algo? Let's suppose it means "in the state at event A".

Then suppose:

• An auth event cited by E is not actually "current" (not in the state at A). So I should reject E?
• An event that would satisfy the auth selection algo is in the state at A, but E does not cite it. So I should reject E?

Discussing with @erikjohnston, neither of these are actually the case. That the cited auth events should be "current" (in the state at A) is merely a suggestion and the expected behaviour of honest participants, but it is not actually enforced. And leaving out any of the auth event types is permissible (due to the ..., if any of all the selection algo clauses), despite them existing in the state of A.

According to Erik, the actual purpose of rule 2.2 is to reject extraneous garbage auth events rather than to specify which auth events (or rather, of which (type, state key) tuples) must be cited.

What should be done?

• Clarify the purpose of auth rule 2.2.
• Make it explicit that qualifying (event type, state key) entries are allowed to be omitted from an event E's auth_events despite existing in the state at the point of the DAG where we are trying to insert E.
• In the selection algo, the status of the following "should" should be clarified and replaced with appropriate RFC2119 wording.
• Clarify what "current" means in the selection algorithm.