add more design details to the readme

README.md

@@ -58,9 +58,22 @@ To update `hishtory` to the latest version, just run `hishtory update` to transp
 
 ## Design
 
-### CLI 
 
-### Syncing
+The `hishtory` CLI is written in Go. It hooks into the shell in order to track information about all commands that are run (specifically in bash this is done via `trap DEBUG` and overriding `$PROMPT_COMMAND`). It takes this data and saves it in a local SQLite DB managed via GORM. When the user runs `hishtory query`, a SQL query is run to find matching entries in the local SQLite DB. 
+
+### Syncing Design 
+
+When `hishtory` is installed, it generates a random secret key. Computers that share a history share this secret key (which is manually copied by the user). It deterministically generates three additional secrets from the secret key:
+
+1. `UserId = HMAC(SecretKey, "user_id")`
+2. `DeviceId = HMAC(SecretKey, "device_id")`
+3. `EncryptionKey = HMAC(SecretKey, "encryption_key")`
+
+At installation time, `hishtory` registers itself with the backend which stores the tuple `(UserId, DeviceId)` which represents a one-to-many relationship between user and devices. 
+
+When a command is run, `hishtory` encrypts (via AES-GCM with `EncryptionKey`) the command (and all the metadata) and sends it to the backend along with the `UserId` to persist it for. The backend retrieves a list of all associated `DeviceId`s and stores a copy of the encrypted blob for each device associated with that user. Once a given device has read an encrypted blob, that entry can be deleted in order to save space (in essence this is a per-device queue, but implemented on top of postgres because this is small scale and I already am running a postgres instance). 
+
+When the user runs `hishtory query`, it retrieves all unread blobs from the backend, decrypts them, and adds them to the local SQLite DB. 
 
 ## Security