MSC4353: Per-origin linear chain - #4353
Conversation
Gnuxie
changed the title
tulir
added
proposal
There was a problem hiding this comment.
Implementation requirements:
- Server
| ### Recovery from downtime/db failure | ||
|
|
||
| Extra care must be taken to ensure that implementations maintain | ||
| knowledge of their forward_extremity. Currently it doesn't matter if a | ||
| server sends events with only partial knowledge of their prior | ||
| history. Implementations may need to query other servers and ensure | ||
| they have complete knowledge of their own forward extremity. |
There was a problem hiding this comment.
I believe that if servers persist events before sending them, then the risk is limited to db recovery. While querying other servers for the extremity may be necessary in that scenario, equally the server key could be rotated within the context of #4345 instead. Which removes the risk entirely.
There was a problem hiding this comment.
Unfortunatly it is entirely possible through a naive db restore that a server sends authorization events that conflict with its prior history that is now unknown to itself. So even if a definition of a traitor is liberalised it's still going to be possible to become one by accident. We don't actually propose that equivicators or inconsistent servers are noted or even acted upon in any way but it's still going to be important that we allow ways out (which key rotation seems to be the best of them).
| ### An example of erasure with linear origin chain | ||
|
|
||
|  | ||
|
|
||
| If Blue does attempt to retroactively erase Yellow, it must explicitly | ||
| create an event that is concurrent with its own origin chain. And thus | ||
| it is observable to everyone that Blue is an equivocator/byzantine | ||
| traitor. As Blue's own events will have multiple causal successors | ||
| sent by Blue. |
There was a problem hiding this comment.
It's still possible to erase history, it's just that doing so without creating a concurrent event requires you to explicitly acknowledge yellow's history as a part of the ban. And if bans are mandated to be scoped to a target's origin predecessor, it is then actually impossible to abuse to erase history. Since a condition for authorising the ban would be not to contradict your own causal frontier in auth rules.
| Green, and Yellow. Consider that Blue immediately bans Yellow after | ||
| Yellow joins the room and the ban event directly references Yellow's | ||
| join in `prev_events`. Consider that concurrent to Blue's ban, | ||
| Yellow sends a message. So that Yellow's join event has to known |
There was a problem hiding this comment.
| Yellow sends a message. So that Yellow's join event has to known | |
| Yellow sends a message. So that Yellow's join event has two known |
| events concurrent to their own causal predecessors without | ||
| explicitly ignoring their maintained forward extremity. The proposal | ||
| does not prevent this, but it does mean that such an equivocation is | ||
| detectable and provable. And so the sender's repuatation can become |
There was a problem hiding this comment.
| detectable and provable. And so the sender's repuatation can become | |
| detectable and provable. And so the sender's reputation can become |
4 participants
Rendered
Signed-off-by: Gnuxie Gnuxie@protonmail.com