|
|
|
@ -472,6 +472,24 @@ The rules are as follows:
|
|
|
|
|
|
|
|
|
|
I think there is some magic about 3pid invites too.
|
|
|
|
|
|
|
|
|
|
Rejection
|
|
|
|
|
+++++++++
|
|
|
|
|
|
|
|
|
|
If an event is rejected it should neither be relayed to clients nor be included
|
|
|
|
|
as a prev event in any new events generated by the server. Subsequent events
|
|
|
|
|
from other servers that reference rejected events should be allowed if they
|
|
|
|
|
still pass the auth rules. The state used in the checks should be calculated as
|
|
|
|
|
normal, except not updating with the rejected event where it is a state event.
|
|
|
|
|
|
|
|
|
|
If an event in an incoming transaction is rejected, this should not cause the
|
|
|
|
|
transaction request to be responded to with an error response.
|
|
|
|
|
|
|
|
|
|
.. NOTE::
|
|
|
|
|
|
|
|
|
|
This means that events may be included in the room DAG even though they
|
|
|
|
|
should be rejected.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Retrieving event authorization information
|
|
|
|
|
++++++++++++++++++++++++++++++++++++++++++
|
|
|
|
|
|
|
|
|
|