diff options
| author | Joey Hess <joeyh@joeyh.name> | 2017-04-27 15:26:50 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2017-04-27 15:55:39 -0400 |
| commit | 686dcc8b172b77e3e612ba4badbb88879d0f5599 (patch) | |
| tree | 5dd568eb15fe1a64a0c77adda8901509396ebd73 /protocol.txt | |
| parent | f6a9cd9c705850a19e2677150c1168bea1a7a9c7 (diff) | |
| download | debug-me-686dcc8b172b77e3e612ba4badbb88879d0f5599.tar.gz | |
Leave the prevMessage out of Activity serialization to save BW.
Do include it in the data that gets signed, so it can be recovered
by trying each likely (recently seen) Activity as the prevMessage, and
checking the signature.
The UserState and DeveloperState already had the necessary state about
recently seen hashes, so this does not impact data use.
One tricky bit is that relayFromSocket needs to wait for the TMChan
to be empty before calling restorePrevActivityHash. Otherwise, the
hashes of items in the channel that have not been processed yet won't be
tried. The TMChan is not really being used as a channel since only 1
item can be in it. It could be converted to a TMVar, but closeTMChan is
used so I left it as a channel.
Note that the server does not restore hashes of messages that pass
through it; it's just a dumb relay.
Sending a single key press now only needs 94 bytes of data to be sent,
down from 169!
---
Also switched to SHA512, since hashes are no longer being sent over
the wire and so the larger size does not matter. SHA512 is slightly
faster and more secure.
This commit was sponsored by Ewen McNeill.
Diffstat (limited to 'protocol.txt')
| -rw-r--r-- | protocol.txt | 7 |
1 files changed, 6 insertions, 1 deletions
diff --git a/protocol.txt b/protocol.txt index 25f239d..d290be7 100644 --- a/protocol.txt +++ b/protocol.txt @@ -21,7 +21,7 @@ Activity Seen and Activity Entered messages have a prevActivity, which points to the Hash of a previous Activity. (And is Nothing for the first Activity Seen.) So a chain of messages is built up. -(The exact details about how these objects are hashed is not described here; +(The exact details about how objects are hashed is not described here; see Hash.hs for the implementation. Note that the JSON strings are *not* directly hashed (to avoid tying hashing to JSON serialization details), instead the values in the data types are hashed.) @@ -88,3 +88,8 @@ before it, etc. Note that there could be multiple developers, in which case each will send their session key before being able to do anything except observe the debug-me session. + +The prevActivity hash is actually not included in the data sent across the +wire. It's left out to save space, and gets added back in by the receiver. +The receiver uses the signature of the message to tell when it's found +the right prevActivity hash to add back in. |