From 496c9e1adf08538da1babf02a69c9a68c8fa38fd Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Fri, 27 Nov 2020 20:37:35 +0000 Subject: [PATCH] More comments on mismatched hashes --- proposals/2836-threading.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/2836-threading.md b/proposals/2836-threading.md index 0a328fc0..26e34844 100644 --- a/proposals/2836-threading.md +++ b/proposals/2836-threading.md @@ -233,7 +233,8 @@ Server behaviour: In addition, if the counts match but the hashes do not match, then the event is unexplored. * Regardless of whether the federated `/event_relationships` request returns the missing children, mark the event as explored afterwards. This prevents constantly hitting federation when walking over this event. The easiest way to mark the event as explored is to remember what the highest children count was - when the most recent federated request was made. If that number differs from the current `unsigned` count then it is unexplored. + when the most recent federated request was made, along with the hash of those children. If that number differs from the current `unsigned` count + or the numbers match but the hashes differ then it is unexplored. - Explored events will always remain up-to-date assuming federation between the two servers remains intact. If there is a long outage, any new child will be marked as "unexplored" (because the parent event will be missing) and trigger an `/event_relationships` request, akin to how the `/send` federation API will trigger `/get_missing_events` in the event of an unknown `prev_event`. This will then pull in events heading up to the root event, along with `unsigned` children