Support alerts (notes, warnings, rationales)
This commit is contained in:
parent
ab64bda76d
commit
338434bfcd
22 changed files with 194 additions and 138 deletions
|
@ -9,12 +9,12 @@ state resolution algorithm.
|
|||
|
||||
## Server implementation components
|
||||
|
||||
Warning
|
||||
|
||||
{{% boxes/warning %}}
|
||||
The information contained in this section is strictly for server
|
||||
implementors. Applications which use the Client-Server API are generally
|
||||
unaffected by the details contained here, and can safely ignore their
|
||||
presence.
|
||||
{{% /boxes/warning %}}
|
||||
|
||||
Room version 2 uses the base components of [room version 1](v1.html),
|
||||
changing only the state resolution algorithm.
|
||||
|
@ -157,8 +157,7 @@ chain should appear in the process, as they should not appear in state
|
|||
(the algorithm only uses events that appear in either the state sets or
|
||||
in the auth chain of the events in the state sets).
|
||||
|
||||
Rationale
|
||||
|
||||
{{% boxes/rationale %}}
|
||||
This helps ensure that different servers' view of state is more likely
|
||||
to converge, since rejection state of an event may be different. This
|
||||
can happen if a third server gives an incorrect version of the state
|
||||
|
@ -182,6 +181,7 @@ Intuitively, using rejected events feels dangerous, however:
|
|||
the event. The duplicated event would then pass the auth checks.
|
||||
Ignoring rejected events would therefore not eliminate any potential
|
||||
attack vectors.
|
||||
{{% /boxes/rationale %}}
|
||||
|
||||
Rejected auth events are deliberately excluded from use in the iterative
|
||||
auth checks, as auth events aren't re-authed (although non-auth events
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue