Add a list command

[da2x]

hyperdrive list keys [--public-key=] [--private-key=]

public-key \t private-key \n

Switches limits output to specific key pairs when one is specified. Can be specified multiple times. Sorted by creation/added timestamp (predictable output order).

hyperdrive list hyperdrives [--write-only] [--read-only]

public-key \t size-in-bytes \t index.json[title] \n

Switches control whether to only include drives with write-access or only read-access (default is both). Sorted by creation/added timestamp (predictable output order).

[andrewosh]

Hey @da2x since this is the first issue of yours I'm replying to, just want to first say thanks for opening them! I think all your suggested CLI improvements would be great to have, and we should work out what would need to be added to the daemon to support each.

That said, these days we're pretty limited when it comes to cycles so we'll have to do a lot of prioritization -- once we've figured out which commands would be reasonable to support near-term, I'd be happy to walk through any potential PRs as well. New CLI commands are very parallelizable :)

list is pretty high on my list (har har), because right now if you aren't using FUSE you have little insight into which drives/keys your daemon's responsible for. I'd suggest splitting up your two use-cases (keys and drives) into separate commands, as key management fits more into backup-oriented workflows (also high on my list).

A few of your suggested switches (created/added) would require storing more info about each drive in the drive database. That'd be a reasonable thing to add, though. Similarly, size-in-bytes can be approximated from the drive's main metadata/content feeds, but making it mount-aware will be tough/expensive. To make it mount-aware you'll need to either:

1. Load every managed drive when you run the list command and do a recursive listing of all mounts -- too expensive.
2. Keep size stats up-to-date when mounts are added/removed/updated -- also expensive because we'll need to do db writes after each file write (or in periodic batches).

On the whole, a simple version of this that just lists keys, gives you readable/writable info, and gives you an approximate size would probably work well enough in the short term, and we're already recording enough info to make the implementation straightforward.