From 1b366b163f283112159a3125c0c9bc622fe684c3 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Fri, 31 Aug 2018 16:01:17 +0100 Subject: [PATCH 01/13] Initial stab at documenting soft fail --- specification/server_server_api.rst | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index 74704faf637..e48bee22ab8 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -570,6 +570,32 @@ transaction request to be responded to with an error response. result in the user being considered joined. +Soft Failure +++++++++++++ + +When the homeserver receives a new event over federation it should also check +whether the event passes auth checks based on the current state of the room +(as well as based on the state at the event). If the event does not pass the +auth checks it should be "soft failed". + +When an event is "soft failed" it should not be relayed to the client nor be +referenced by new events created by the homeserver. If an event is received that +references the soft failed event then the new event should be handled as usual. +If this causes a change in state (e.g. due to the soft failed event being a +state event) then the state updates should be propagated to clients as usual. + +.. NOTE:: + + This is different than rejections in that soft failed events are simply + ignored unless a new event references it. + + +.. NOTE:: + + Soft failures are designed to stop malicious servers from avoiding actions + such as kicks or bans by careful selection of ``prev_events``. + + Retrieving event authorization information ++++++++++++++++++++++++++++++++++++++++++ From 6a035cca63b7a96b1262a147dd295df25676d1fb Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Fri, 31 Aug 2018 16:08:13 +0100 Subject: [PATCH 02/13] Title casing --- specification/server_server_api.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index e48bee22ab8..990eda4247b 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -570,7 +570,7 @@ transaction request to be responded to with an error response. result in the user being considered joined. -Soft Failure +Soft failure ++++++++++++ When the homeserver receives a new event over federation it should also check From cafe7064ec4e68760b72f01e517843c8b08e87d5 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Tue, 2 Oct 2018 14:05:55 +0100 Subject: [PATCH 03/13] Clarify whether to return soft failed events are returned in federation API --- specification/server_server_api.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index 990eda4247b..277c649a4ad 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -584,6 +584,11 @@ references the soft failed event then the new event should be handled as usual. If this causes a change in state (e.g. due to the soft failed event being a state event) then the state updates should be propagated to clients as usual. +A soft failed event should be returned in response to federation requests +where appropriate (e.g. in ``/event/``). Note that soft failed events +are returned in ``/backfill`` and ``/get_missing_events`` responses only if the +requests include events referencing the soft failed events. + .. NOTE:: This is different than rejections in that soft failed events are simply From ed9f05d107c8ddf5a4e51959cc6471566b964cb0 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Wed, 17 Oct 2018 11:23:10 +0100 Subject: [PATCH 04/13] Clarify soft failed state event handling --- specification/server_server_api.rst | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index 277c649a4ad..b6c23224805 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -579,10 +579,13 @@ whether the event passes auth checks based on the current state of the room auth checks it should be "soft failed". When an event is "soft failed" it should not be relayed to the client nor be -referenced by new events created by the homeserver. If an event is received that -references the soft failed event then the new event should be handled as usual. -If this causes a change in state (e.g. due to the soft failed event being a -state event) then the state updates should be propagated to clients as usual. +referenced by new events created by the homeserver. + +If an event is received that references the soft failed event then the new event +should be handled as usual. Soft failed state events participate in state +resolution, and so can appear in the state of events that reference the soft +failed state event. (When this happens the soft failed event should be sent to +clients). A soft failed event should be returned in response to federation requests where appropriate (e.g. in ``/event/``). Note that soft failed events From 7b28b1989c83f835558018cb37b1c604c9d313f4 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Wed, 17 Oct 2018 17:32:42 +0100 Subject: [PATCH 05/13] Further clarifications --- specification/server_server_api.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index b6c23224805..a8f9f281b50 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -584,8 +584,10 @@ referenced by new events created by the homeserver. If an event is received that references the soft failed event then the new event should be handled as usual. Soft failed state events participate in state resolution, and so can appear in the state of events that reference the soft -failed state event. (When this happens the soft failed event should be sent to -clients). +failed state event. This can result in soft-failed events appearing in the state +of allowed events, in which case the client should be told about the soft failed +event in the usual way (e.g. by sending it down in the ``state`` section of a +sync response). A soft failed event should be returned in response to federation requests where appropriate (e.g. in ``/event/``). Note that soft failed events From 6445899c5c20638ff47e3aa8652bed55df174523 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 18 Oct 2018 11:25:42 +0100 Subject: [PATCH 06/13] Clarify soft fail being due to not passing auth based on current state --- specification/server_server_api.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index a8f9f281b50..be96616cf41 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -574,9 +574,10 @@ Soft failure ++++++++++++ When the homeserver receives a new event over federation it should also check -whether the event passes auth checks based on the current state of the room -(as well as based on the state at the event). If the event does not pass the -auth checks it should be "soft failed". +whether the event passes auth checks based on the current state of the room (as +well as based on the state at the event). If the event does not pass the auth +checks based on the current state of the room (but does pass the auth checks +based on the state at that event) it should be "soft failed". When an event is "soft failed" it should not be relayed to the client nor be referenced by new events created by the homeserver. From 43d2d82cbc92a28113413aab5160269a054872d1 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 18 Oct 2018 11:55:56 +0100 Subject: [PATCH 07/13] Add an attempt at an example --- specification/server_server_api.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index be96616cf41..6475dd2f1f6 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -607,6 +607,28 @@ requests include events referencing the soft failed events. such as kicks or bans by careful selection of ``prev_events``. +As an example consider the following graph:: + + A + / \ + B C + \ / + D + +Where ``A`` is the oldest event, ``B`` bans the sender of ``C`` and ``C`` is a +topic change. If a server S1 receives ``B`` and then ``C`` then it will soft +fail ``C``. This means that S1 won't relay ``C`` to its clients, and won't send +any events referencing ``C``. If later another server S2 sends an event ``D`` +that references both ``B`` and ``C`` (this can happen if S2 received ``C`` +before ``B``) then S1 will handle ``D`` as normal. ``D`` is sent to the clients +of S1 (assuming ``D`` passes auth checks). The state at ``D`` may resolve to a +state that includes ``C``, in which case clients should also to be told that the +has changed to include ``C``. + +Note that this is essentially equivalent to the situation where S1 doesn't +receive ``C`` at all, and so asks S2 for the state of the ``C`` branch. + + Retrieving event authorization information ++++++++++++++++++++++++++++++++++++++++++ From f3f115153f8756917a77e20c824c8e9425ee6538 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 18 Oct 2018 13:35:41 +0100 Subject: [PATCH 08/13] Rework entire thing to add motivation, then implementation and then worked examples --- specification/server_server_api.rst | 92 +++++++++++++++++++++-------- 1 file changed, 66 insertions(+), 26 deletions(-) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index 6475dd2f1f6..22770920cd7 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -573,6 +573,25 @@ transaction request to be responded to with an error response. Soft failure ++++++++++++ +Motivation +"""""""""" + +If a user is banned from a room a server can still send events from them by only +referencing events from before the ban. This allows fairly simple ban evasion. +(This can also be abused when a user loses other privileges, like power levels, +etc). + +When this happens it is often fairly obvious to servers, as they can see that +the new event doesn't actually pass auth based on the "current state" (i.e. the +resolved state across all forward extremities). While the event is technically +valid, the server can choose to not notify clients about the new event. + +This discourages servers from sending events that evade bans etc. in this way, +as end users won't actually see the events. + +Implementation +"""""""""""""" + When the homeserver receives a new event over federation it should also check whether the event passes auth checks based on the current state of the room (as well as based on the state at the event). If the event does not pass the auth @@ -582,32 +601,43 @@ based on the state at that event) it should be "soft failed". When an event is "soft failed" it should not be relayed to the client nor be referenced by new events created by the homeserver. -If an event is received that references the soft failed event then the new event -should be handled as usual. Soft failed state events participate in state -resolution, and so can appear in the state of events that reference the soft -failed state event. This can result in soft-failed events appearing in the state -of allowed events, in which case the client should be told about the soft failed -event in the usual way (e.g. by sending it down in the ``state`` section of a -sync response). +.. NOTE:: + + If an event is received that references the soft failed event then the new event + should be handled as usual. Soft failed state events participate in state + resolution, and so can appear in the state of events that reference the soft + failed state event. This can result in soft-failed events appearing in the state + of allowed events, in which case the client should be told about the soft failed + event in the usual way (e.g. by sending it down in the ``state`` section of a + sync response). -A soft failed event should be returned in response to federation requests -where appropriate (e.g. in ``/event/``). Note that soft failed events -are returned in ``/backfill`` and ``/get_missing_events`` responses only if the -requests include events referencing the soft failed events. + A soft failed event should be returned in response to federation requests + where appropriate (e.g. in ``/event/``). Note that soft failed events + are returned in ``/backfill`` and ``/get_missing_events`` responses only if the + requests include events referencing the soft failed events. -.. NOTE:: - This is different than rejections in that soft failed events are simply - ignored unless a new event references it. +Worked Examples +""""""""""""""" +As an example consider the event graph:: -.. NOTE:: + A + / + B + +Where ``B`` is a ban of a user ``X``. If the user ``X`` tries to set the topic +by sending an event ``C`` while evading the ban:: - Soft failures are designed to stop malicious servers from avoiding actions - such as kicks or bans by careful selection of ``prev_events``. + A + / \ + B C +Servers that receive ``C`` after ``B`` will soft fail event ``C``, and so will +neither relay ``C`` to its clients nor send any events referencing ``C``. -As an example consider the following graph:: +If later another server sends an event ``D`` that references both ``B`` and +``C`` (this can happen if it received ``C`` before ``B``):: A / \ @@ -615,19 +645,29 @@ As an example consider the following graph:: \ / D -Where ``A`` is the oldest event, ``B`` bans the sender of ``C`` and ``C`` is a -topic change. If a server S1 receives ``B`` and then ``C`` then it will soft -fail ``C``. This means that S1 won't relay ``C`` to its clients, and won't send -any events referencing ``C``. If later another server S2 sends an event ``D`` -that references both ``B`` and ``C`` (this can happen if S2 received ``C`` -before ``B``) then S1 will handle ``D`` as normal. ``D`` is sent to the clients -of S1 (assuming ``D`` passes auth checks). The state at ``D`` may resolve to a -state that includes ``C``, in which case clients should also to be told that the +Then servers will handle ``D`` as normal. ``D`` is sent to the servers' clients +(assuming ``D`` passes auth checks). The state at ``D`` may resolve to a state +that includes ``C``, in which case clients should also to be told that the state has changed to include ``C``. Note that this is essentially equivalent to the situation where S1 doesn't receive ``C`` at all, and so asks S2 for the state of the ``C`` branch. +Let's go back to the graph before ``D`` was sent:: + + A + / \ + B C + +If all the servers in the room saw ``B`` before ``C`` and so soft fail ``C``, +then any new event ``D'`` will not reference ``C``:: + + A + / \ + B C + | + D + Retrieving event authorization information ++++++++++++++++++++++++++++++++++++++++++ From 0d9b882f0124e73d168fd878dcdceccc70a0fc96 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 18 Oct 2018 13:39:02 +0100 Subject: [PATCH 09/13] Try different title character --- specification/server_server_api.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index 22770920cd7..657976895f4 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -574,7 +574,7 @@ Soft failure ++++++++++++ Motivation -"""""""""" +^^^^^^^^^^ If a user is banned from a room a server can still send events from them by only referencing events from before the ban. This allows fairly simple ban evasion. @@ -590,7 +590,7 @@ This discourages servers from sending events that evade bans etc. in this way, as end users won't actually see the events. Implementation -"""""""""""""" +^^^^^^^^^^^^^^ When the homeserver receives a new event over federation it should also check whether the event passes auth checks based on the current state of the room (as @@ -618,7 +618,7 @@ referenced by new events created by the homeserver. Worked Examples -""""""""""""""" +^^^^^^^^^^^^^^^ As an example consider the event graph:: From ceb7494637cf73b6c293d8b70c797134eaf3fa1c Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Tue, 23 Oct 2018 14:33:54 +0100 Subject: [PATCH 10/13] Use Rationale and Example admonitions, rather than headings --- scripts/css/nature.css | 5 ++ specification/server_server_api.rst | 84 ++++++++++++++--------------- 2 files changed, 45 insertions(+), 44 deletions(-) diff --git a/scripts/css/nature.css b/scripts/css/nature.css index 0fdcc55ad50..a4fcdfe1bc4 100644 --- a/scripts/css/nature.css +++ b/scripts/css/nature.css @@ -284,3 +284,8 @@ div.admonition-rationale { border: 1px solid #ccc; } +div.admonition-example { + background-color: #eef; + border: 1px solid #ccc; +} + diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index 657976895f4..cfbf8b81db8 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -573,24 +573,21 @@ transaction request to be responded to with an error response. Soft failure ++++++++++++ -Motivation -^^^^^^^^^^ +.. admonition:: Rationale -If a user is banned from a room a server can still send events from them by only -referencing events from before the ban. This allows fairly simple ban evasion. -(This can also be abused when a user loses other privileges, like power levels, -etc). + If a user is banned from a room a server can still send events from them by + only referencing events from before the ban. This allows fairly simple ban + evasion. (This can also be abused when a user loses other privileges, like + power levels, etc). -When this happens it is often fairly obvious to servers, as they can see that -the new event doesn't actually pass auth based on the "current state" (i.e. the -resolved state across all forward extremities). While the event is technically -valid, the server can choose to not notify clients about the new event. + When this happens it is often fairly obvious to servers, as they can see that + the new event doesn't actually pass auth based on the "current state" (i.e. + the resolved state across all forward extremities). While the event is + technically valid, the server can choose to not notify clients about the new + event. -This discourages servers from sending events that evade bans etc. in this way, -as end users won't actually see the events. - -Implementation -^^^^^^^^^^^^^^ + This discourages servers from sending events that evade bans etc. in this way, + as end users won't actually see the events. When the homeserver receives a new event over federation it should also check whether the event passes auth checks based on the current state of the room (as @@ -603,41 +600,40 @@ referenced by new events created by the homeserver. .. NOTE:: - If an event is received that references the soft failed event then the new event - should be handled as usual. Soft failed state events participate in state - resolution, and so can appear in the state of events that reference the soft - failed state event. This can result in soft-failed events appearing in the state - of allowed events, in which case the client should be told about the soft failed - event in the usual way (e.g. by sending it down in the ``state`` section of a - sync response). + If an event is received that references the soft failed event then the new + event should be handled as usual. Soft failed state events participate in + state resolution, and so can appear in the state of events that reference the + soft failed state event. This can result in soft-failed events appearing in + the state of allowed events, in which case the client should be told about the + soft failed event in the usual way (e.g. by sending it down in the ``state`` + section of a sync response). - A soft failed event should be returned in response to federation requests - where appropriate (e.g. in ``/event/``). Note that soft failed events - are returned in ``/backfill`` and ``/get_missing_events`` responses only if the - requests include events referencing the soft failed events. + A soft failed event should be returned in response to federation requests + where appropriate (e.g. in ``/event/``). Note that soft failed + events are returned in ``/backfill`` and ``/get_missing_events`` responses + only if the requests include events referencing the soft failed events. -Worked Examples -^^^^^^^^^^^^^^^ +.. admonition:: Example -As an example consider the event graph:: + As an example consider the event graph:: A / B -Where ``B`` is a ban of a user ``X``. If the user ``X`` tries to set the topic -by sending an event ``C`` while evading the ban:: + Where ``B`` is a ban of a user ``X``. If the user ``X`` tries to set the topic + by sending an event ``C`` while evading the ban:: A / \ B C -Servers that receive ``C`` after ``B`` will soft fail event ``C``, and so will -neither relay ``C`` to its clients nor send any events referencing ``C``. + Servers that receive ``C`` after ``B`` will soft fail event ``C``, and so will + neither relay ``C`` to its clients nor send any events referencing ``C``. -If later another server sends an event ``D`` that references both ``B`` and -``C`` (this can happen if it received ``C`` before ``B``):: + If later another server sends an event ``D`` that references both ``B`` and + ``C`` (this can happen if it received ``C`` before ``B``):: A / \ @@ -645,22 +641,22 @@ If later another server sends an event ``D`` that references both ``B`` and \ / D -Then servers will handle ``D`` as normal. ``D`` is sent to the servers' clients -(assuming ``D`` passes auth checks). The state at ``D`` may resolve to a state -that includes ``C``, in which case clients should also to be told that the state -has changed to include ``C``. + Then servers will handle ``D`` as normal. ``D`` is sent to the servers' + clients (assuming ``D`` passes auth checks). The state at ``D`` may resolve to + a state that includes ``C``, in which case clients should also to be told that + the state has changed to include ``C``. -Note that this is essentially equivalent to the situation where S1 doesn't -receive ``C`` at all, and so asks S2 for the state of the ``C`` branch. + Note that this is essentially equivalent to the situation where S1 doesn't + receive ``C`` at all, and so asks S2 for the state of the ``C`` branch. -Let's go back to the graph before ``D`` was sent:: + Let's go back to the graph before ``D`` was sent:: A / \ B C -If all the servers in the room saw ``B`` before ``C`` and so soft fail ``C``, -then any new event ``D'`` will not reference ``C``:: + If all the servers in the room saw ``B`` before ``C`` and so soft fail ``C``, + then any new event ``D'`` will not reference ``C``:: A / \ From 377e02a80f620f7a96cd0f43d7f3358e0ec2354d Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Tue, 23 Oct 2018 14:45:01 +0100 Subject: [PATCH 11/13] Fix up example section --- specification/server_server_api.rst | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index cfbf8b81db8..3fb6e7d4d43 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -622,15 +622,15 @@ referenced by new events created by the homeserver. / B - Where ``B`` is a ban of a user ``X``. If the user ``X`` tries to set the topic + where ``B`` is a ban of a user ``X``. If the user ``X`` tries to set the topic by sending an event ``C`` while evading the ban:: A / \ B C - Servers that receive ``C`` after ``B`` will soft fail event ``C``, and so will - neither relay ``C`` to its clients nor send any events referencing ``C``. + servers that receive ``C`` after ``B`` should soft fail event ``C``, and so + will neither relay ``C`` to its clients nor send any events referencing ``C``. If later another server sends an event ``D`` that references both ``B`` and ``C`` (this can happen if it received ``C`` before ``B``):: @@ -641,13 +641,17 @@ referenced by new events created by the homeserver. \ / D - Then servers will handle ``D`` as normal. ``D`` is sent to the servers' + then servers will handle ``D`` as normal. ``D`` is sent to the servers' clients (assuming ``D`` passes auth checks). The state at ``D`` may resolve to a state that includes ``C``, in which case clients should also to be told that - the state has changed to include ``C``. - - Note that this is essentially equivalent to the situation where S1 doesn't - receive ``C`` at all, and so asks S2 for the state of the ``C`` branch. + the state has changed to include ``C``. (*Note*: This depends on the exact + state resolution algorithm used. In the original version of the algorithm + ``C`` would be in the resolved state, whereas in latter versions this may not + be the case.) + + Note that this is essentially equivalent to the situation where one server + doesn't receive ``C`` at all, and so asks another server for the state of the + ``C`` branch. Let's go back to the graph before ``D`` was sent:: From 56b28879c6ee4c52a04fdca63472ba9c98f0545e Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Tue, 23 Oct 2018 16:51:26 +0100 Subject: [PATCH 12/13] Incorporate feedback --- specification/server_server_api.rst | 44 ++++++++++++++++++++--------- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index 3fb6e7d4d43..717d1e0ae2d 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -575,10 +575,16 @@ Soft failure .. admonition:: Rationale - If a user is banned from a room a server can still send events from them by - only referencing events from before the ban. This allows fairly simple ban - evasion. (This can also be abused when a user loses other privileges, like - power levels, etc). + It is important that we prevent users from evading bans (or other power + restrictions) by creating events which reference old parts of the DAG. For + example, a banned user could continue to send messages to a room by having + their server send events which reference the event before they were banned. + Note that such events are entirely valid, and we cannot simply reject them, as + it is impossible to distinguish such an event from a legitimate one which has + been delayed. We must therefore accept such events and let them participate in + state resolution and the federation protocol as normal. However, servers may + choose not to send such events on to their clients, so that end users won't + actually see the events. When this happens it is often fairly obvious to servers, as they can see that the new event doesn't actually pass auth based on the "current state" (i.e. @@ -589,24 +595,36 @@ Soft failure This discourages servers from sending events that evade bans etc. in this way, as end users won't actually see the events. + When the homeserver receives a new event over federation it should also check whether the event passes auth checks based on the current state of the room (as well as based on the state at the event). If the event does not pass the auth -checks based on the current state of the room (but does pass the auth checks +checks based on the *current state* of the room (but does pass the auth checks based on the state at that event) it should be "soft failed". When an event is "soft failed" it should not be relayed to the client nor be -referenced by new events created by the homeserver. +referenced by new events created by the homeserver (i.e. they should not be +added to the server's list of forward extremities of the room). Soft failed +events are otherwise handled as usual. + .. NOTE:: - If an event is received that references the soft failed event then the new - event should be handled as usual. Soft failed state events participate in - state resolution, and so can appear in the state of events that reference the - soft failed state event. This can result in soft-failed events appearing in - the state of allowed events, in which case the client should be told about the - soft failed event in the usual way (e.g. by sending it down in the ``state`` - section of a sync response). + Soft failed events participate in state resolution as normal if further events + are received which reference it. It is the job of the state resolution + algorithm to ensure that malicious events cannot be injected into the room + state via this mechanism. + + +.. NOTE:: + + Because soft failed state events participate in state resolution as normal, it + is possible for such events to appear in the current state of the room. In + that case the client should be told about the soft failed event in the usual + way (e.g. by sending it down in the ``state`` section of a sync response). + + +.. NOTE:: A soft failed event should be returned in response to federation requests where appropriate (e.g. in ``/event/``). Note that soft failed From 40bc911f5cc68be2b332a2bc68a45a721d2cc237 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Fri, 26 Oct 2018 15:16:17 +0100 Subject: [PATCH 13/13] Add requested from Matthew to talk about future state res algorithms --- specification/server_server_api.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/specification/server_server_api.rst b/specification/server_server_api.rst index 717d1e0ae2d..899d914c8b3 100644 --- a/specification/server_server_api.rst +++ b/specification/server_server_api.rst @@ -664,8 +664,8 @@ events are otherwise handled as usual. a state that includes ``C``, in which case clients should also to be told that the state has changed to include ``C``. (*Note*: This depends on the exact state resolution algorithm used. In the original version of the algorithm - ``C`` would be in the resolved state, whereas in latter versions this may not - be the case.) + ``C`` would be in the resolved state, whereas in latter versions the algorithm + tries to prioritise the ban over the topic change.) Note that this is essentially equivalent to the situation where one server doesn't receive ``C`` at all, and so asks another server for the state of the