diff options
Diffstat (limited to 'protocol.txt')
| -rw-r--r-- | protocol.txt | 41 |
1 files changed, 30 insertions, 11 deletions
diff --git a/protocol.txt b/protocol.txt index 06c9454..10829c5 100644 --- a/protocol.txt +++ b/protocol.txt @@ -3,14 +3,12 @@ the two participants, known as the user and the developer. The exact composition of the JSON objects is not described here; see Types.hs for the data types that JSON serialization instances are derived -from. +from. The Activity type is the main message type. -A debug-me session starts with the user sending an Activity Seen -containing an introductory message, eg "debug-me session started". -This first Activity Seen has Nothing as its prevActivity. All -subsequent Activity sent by either the user or developer must have a -prevActivity that points to the Hash of the previous activity. -So a chain of Activity is built up. +The first message in a debug-me session is sent by the user, and it has +Nothing as its prevActivity. All subsequent messages sent by either the +user or the developer must have a prevActivity that points to the Hash +of a previous message. So a chain of messages is built up. The exact details about how these objects are hashed is not described here; see Hash.hs for the implementation. Note that the JSON strings are *not* @@ -26,9 +24,9 @@ about it. Since the goal of debug-me is to produce a proof of the sequence of events that occurred in a session, that is a problem. Perhaps the developer was -entering "y" in response to "Shutdown reactor?" at the same time +entering "y" in response to "Display detailed reactor logs?" at the same time that a new "Vent core to atmosphere?" question was being displayed! -So, the debug-me protocol is designed to prevent such conflicts of opinion. +The debug-me protocol is designed to prevent such conflicts of opinion. The user only processes a new Activity Entered when either: @@ -42,8 +40,8 @@ The user only processes a new Activity Entered when either: (This allows the developer to enter a command quickly without waiting for each letter to echo back to them.) -When an Activity Entered does not meet these rules, the user sends it -back in a Rejected message to let the developer know the input was not +When an Activity Entered does not meet these rules, the user sends +it back in a Rejected message to let the developer know the input was not allowed. The developer also checks the prevActivity of messages it receives @@ -55,3 +53,24 @@ The developer accepts a new Activity Seen when either: 2. The Activity Seen has as its prevActivity an Activity Entered that the developer generated, after the last Activity Seen that the developer accepted. + +At the start of the debug-me session, Ed25519 session key pairs are +generated by both the user and the developer. The very first +message in the protocol is the user sending their session pubic key. + +Before the developer can do anything, they must send a message with their +session key, and it must be accepted by the user. The developer must have +a gpg private key, which is used to sign their session key. +(The user may have a gpg private key, which will sign their session key +if available, but this is optional.) The user will reject session keys +that are not signed by a gpg key or when the gpg key is not one they +trust. + +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. + +Each message in the debug-me session is signed by the party that sends it, +using their session key. The hash of a message includes its signature, so +the activity chain proves who sent a message, and who sent the message its +prevActivity points to, etc. |