https://github.com/NixOS/nix/blob/master/src/libstore/remote-store.cc
https://github.com/bazelbuild/remote-apis/blob/main/build/bazel/remote/execution/v2/remote_execution.proto

## remote store
- works by ssh
- ssh in and call a binary
- communicates by stdin / stdout
- we write that binary
- nix-remote-build --custom-command <ours>
  - not actual flag

## protocol
- custom serialization
  - everything padded to n*64 bits
  - i64 (little-endian)
  - String (len: u64, data, padding) 
- wop*
  - ops for messages server -> client
  - some obsolete
  - correspond to functions on the client
  - lots of things depend on the version of the protocol
    - (at first) ignore this and implement latest version

## first steps
- capture commands & don't do much
- need to send something back
- forward to regular binary?
- another implementation of the same protocol is useful on its own

- enum for operations
- wire protocol

## bazel RE protocol

- on EnsurePath we could do substitution (using the blob cache). Why do we sometimes get AddToStore and sometimes EnsurePath?
- build an adaptation from nix store <-> bazel ca store
  it seems like nix calls AddToStore in dependency order, giving us the content each time, so we can compute the ca hashes
- encode a nix store path as an action in the action cache (action cache maps from the input hash of a build action to
  its output hashes)
- nix store queries can be turned into bazel actions

- using nix as a remote builder seems much easier. From a clean nix store, the ops go:
  - QueryValidPaths for the paths we want. Returns empty (when builders_use_substitutes is true, the builder does the downloading and returns the full set of paths)
  - AddMultipleToStore for adding everything
  - BuildDerivation build everything
  - QueryPathInfo