|
|
|
@ -132,12 +132,13 @@ chain for those auth events.
|
|
|
|
|
Auth chain resolution
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
**TODO**: If an auth check fails, or if we get told something we accepted
|
|
|
|
|
should have been rejected, we need to try and determine who is right.
|
|
|
|
|
If an auth check fails, or if we get told something we accepted should have
|
|
|
|
|
been rejected, we need to try and determine who is right.
|
|
|
|
|
|
|
|
|
|
Both should inform the other of what they think the current auth chain is. If
|
|
|
|
|
either are missing auth events that they know are valid (through authorization
|
|
|
|
|
and state resolution) they process the missing events as usual.
|
|
|
|
|
If two servers disagree about the validity of the auth events, both should
|
|
|
|
|
inform the other of what they think the current auth chain is. If either are
|
|
|
|
|
missing auth events that they know are valid (through authorization and state
|
|
|
|
|
resolution) they process the missing events as usual.
|
|
|
|
|
|
|
|
|
|
If either side notice that the other has accepted an auth events we think
|
|
|
|
|
should be rejected (for reasons *not* in their auth chain), that server should
|
|
|
|
|