From b695eb0d17c6f8ea49e7f190e9d19fddf84eed21 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Thu, 13 Dec 2018 11:20:19 +0000 Subject: [PATCH] Clarify example --- proposals/1442-state-resolution.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/proposals/1442-state-resolution.md b/proposals/1442-state-resolution.md index 64a74d96..76abacce 100644 --- a/proposals/1442-state-resolution.md +++ b/proposals/1442-state-resolution.md @@ -488,7 +488,7 @@ event. # Appendix -## Example 1 +## Example 1 - Mainline The following is an example room DAG, where time flows down the page. We shall work through resolving the state at both _Message 2_ and _Message 3_. @@ -545,7 +545,7 @@ auth checks, and so the last topic, _Topic 4_, is chosen. This gives the resolved state at _Message 3_ to be _Topic 4_. -## Example 2 +## Example 2 - Rejected Events The following is an example room DAG, where time flows down the page. The event `D` is initially rejected by the server (due to not passing auth against the @@ -553,9 +553,12 @@ state), but does pass auth against its auth chain. ![state-res-rejected.png](images/state-res-rejected.png) +(Note that the blue lines are the power levels pointed to in the event's auth +events) + At `F` we first resolve the power levels, which results in `E`. When we then go -to resolve the topics against the partially resolved state Bob has ops, and so -the resolved state include the topic change `D`, even though it was initially +to resolve the topics against the partially resolved state, Bob has ops and so +the resolved state includes the topic change `D`, even though it was initially rejected.