diff options
author | Joey Hess <joeyh@joeyh.name> | 2017-05-02 15:52:27 -0400 |
---|---|---|
committer | Joey Hess <joeyh@joeyh.name> | 2017-05-02 17:01:35 -0400 |
commit | f559fcfadd7079140ed64bab68275527f46d334e (patch) | |
tree | 1f30f563093a27188a5b1da37aa764f4e58c0393 /TODO | |
parent | 9456361ed8f6dd094a4c08cc352f9a1fd9d0069f (diff) | |
download | debug-me-f559fcfadd7079140ed64bab68275527f46d334e.tar.gz |
add prevEntered pointer
Client requires this always point to the previous Entered it accepted,
so a hash chain of Entered is built up, and there is no possibility for
ambiguity about which order a client received two Entered activies in.
So restoreHashes now has to try every possible combination of
known hashes for both prevEntered and prevActivity. That could be
significantly more work, but it would be unusual for there to be a lot
of known hashes, so it should be ok.
--graphviz shows this additional hash chain with grey edges
(and leaves out edges identical to the other hash chain)
While testing this with an artifical network lag, it turned out that
signature verification was failing for Reject messages sent by the
user. Didn't quite figure out what was at the bottom of that,
but the Activity Entered that was sent back in a Reject message was
clearly not useful, because it probably had both its prevEntered and
prevActivity hashes set to Nothing (because restoreHashes didn't restore
them, because the original Activity Entered was out of the expected
chain). So, switched Rejected to use a Hash.
(And renamed Rejected to EnteredRejected to make it more clear what
it's rejecting.)
Also, added a lastAccepted hash to EnteredRejected. This lets
the developer find its way back to the accepted chain when some
of its input gets rejected.
This commit was sponsored by Trenton Cronholm on Patreon.
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 25 |
1 files changed, 0 insertions, 25 deletions
@@ -1,28 +1,3 @@ -* The current rules for when an Activity Entered is accepted allow it to - refer to an older activity than the last one. If echoing is disabled, - two Activity Entered could be sent, each pointing at the most recent - Activity Seen, and there would be no proof of the order of the two. - Reordering the two might cause different results though. - - This is not only a problem when 2 developers are connected; it also - lets a single developer produce a proof chain that is ambiguous about - what order they entered 2 things. - - Fix: Make a Activity Entered have a pointer to the previous Activity - Entered that was accepted, in addition to the existing pointer. Then - when one developer sends two Activity Entered that don't echo, there's - still proof of ordering. When two developers are typing at the same - time, only one of their inputs will be accepted. The client should only - consider an Activity Entered legal if it points to the last Activity - Entered that the client saw. - - May as well make Activity Seen have a pointer to the last accepted - Activity Entered as well. This will make it easier when supported - multiple developers, as each time a developer gets an Activity Seen, - they can update their state to use the Activity Entered that it points - to. (Perhaps not needed now that developers see other developer's - Activity Entered.. But, this does let developers know what the current - accepted line is.) * Client should upload to multiple servers, for redundancy. This way, if Joey runs a server, and Alice runs a server, the user can start debug-me and not worry that Joey will connect, do something bad, and have |