From 5c2b8e35693c311e77781e78b7b3dbfdc1fae244 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 30 Aug 2018 17:03:16 +0100 Subject: [PATCH 1/3] Explain how to handle rejeceted events --- specification/server_server_api.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index 244a8b82..4c40d6dc 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -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 ++++++++++++++++++++++++++++++++++++++++++ From ebb044674f0b83d41ce4c1a323a813162f3821f8 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Fri, 31 Aug 2018 09:51:17 +0100 Subject: [PATCH 2/3] Remove duplicated explanation about event rejection --- specification/server_server_api.rst | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index 4c40d6dc..2677cf3a 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -345,17 +345,6 @@ be inserted. The types of state events that affect authorization are: - ``m.room.join_rules`` - ``m.room.power_levels`` -Servers should not create new events that reference unauthorized events. -However, any event that does reference an unauthorized event is not itself -automatically considered unauthorized. - -Unauthorized events that appear in the event graph do *not* have any effect on -the state of the room. - -.. Note:: This is in contrast to redacted events which can still affect the - state of the room. For example, a redacted ``join`` event will still - result in the user being considered joined. - The rules are as follows: 1. If type is ``m.room.create``, allow if and only if it has no From 4d653748d60abfb631ed1c8fbbd3c5a19eca7721 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Fri, 31 Aug 2018 11:17:58 +0100 Subject: [PATCH 3/3] Add note back in --- specification/server_server_api.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index 2677cf3a..19f0fb78 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -478,6 +478,12 @@ transaction request to be responded to with an error response. This means that events may be included in the room DAG even though they should be rejected. +.. NOTE:: + + This is in contrast to redacted events which can still affect the + state of the room. For example, a redacted ``join`` event will still + result in the user being considered joined. + Retrieving event authorization information ++++++++++++++++++++++++++++++++++++++++++