-
-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minor drive-by state res clarifications #1042
Minor drive-by state res clarifications #1042
Conversation
Fixes #1041
Co-authored-by: Denis Kasak <[email protected]>
@DMRobertson is this still WIP? Title and state don't seem to match |
No, thanks; title updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
definitely an improvement!
unconflicted state map only has one event per `(event_type, state_key)`, | ||
whereas the conflicted state set may have multiple events. | ||
The key-value pairs across all state maps *S<sub>i</sub>* can be divided into | ||
two collections. If a given key *K* is present in every *S<sub>i</sub>* with the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it obvious that K is a (event_type, state_key)
pair, or is there a way we can make that obvious?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be helpful if there was a phrase which meant (event_type, state_key)
. How about 8ab0634?
*unconflicted state map*. Otherwise (*K*, *V*) belongs to the | ||
*conflicted state set*. | ||
|
||
Note that the unconflicted state map only has one event per `(event_type, state_key)`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... switching from K to (event_type, state_key)
here is jarring without that context.
|
||
**Auth chain.** | ||
The *auth chain* of an event *E* is the set containing all of *E*'s auth events, | ||
all of *their* authorising events, and so on recursively, stretching back to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
possibly we should stick to the term "auth events" rather than switching to "authorising events" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is 8c49f00
Co-authored-by: Richard van der Hoff <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!
In #1042 I incorrectly wrote that the conflicted state set is a set of pairs (K, V). We later take the union of the conflicted state set and the auth difference. The latter is a set of events (V) only. Fix this by making the conflicted state set a set of events rather than a set of pairs. That is, the conflicted state set is a a `Set[Event]` instead of a `Set[((type, state key), event)]`.
Depends on #1037.
Fixes #1041.
Preview: https://pr1042--matrix-spec-previews.netlify.app