RFC: drop CLI-console overlap, all iroh commands start a node

[b5]

Background

Iroh requires a running node to do anything interesting. We have the ability spin up an iroh node quickly, either in-memory or bound to a local filesystem. We've developed this for both fast internal testing and to support "one off" use cases that quickly get or provide data. The classic example is iroh get, a "curl for iroh data" that runs a node just long enough to fetch the data, and then turn off again. In fact, this incarnation of iroh started off as a tool called sendme that only worked this way.

The problem is mixing UX. Some commands requiring iroh start and others not having this requirement is very confusing to the end user.

Our original plan for solving this was to build iroh console, and always require iroh start be running. We wanted to give users a consistent interface that yes adds an early learning hurdle ("you need to run iroh before you can do anything"), but once they clear that hurdle.

We've gotten muddled up & ended up implementing both the console and CLI versions of all the same commands, largely because clap made it easy to do it, so we did. The CLI experience is far worse than the console for all things except the iroh start $PATH -> iroh get pattern, which has seen all sorts of real world use.

Users have clearly expressed a desire for both "one off" and "long lived" commands. At the same time, I really don't think anyone is using the CLI versions of console commands, which leaves room to clean things up a bit.

Proposal

This proposal aims to remedy the situation by stripping away what doesn't work, and introducing the new hueristic that all iroh commands will start a node if one is not running.

• remove all commands that are currently available in the console: doctor, doc, author, blob, node, and tag are removed
• add a new command iroh exec that accepts console command(s) & prints the output
• rename the iroh start command to iroh
• modify the iroh console command to start iroh node if one is not running, presents a warning to the user with a documentation link

After these changes:

$ iroh help
Sync Anywhere
https://iroh.computer/docs

Usage: iroh [OPTIONS] <COMMAND>

Commands:
  start    Start an iroh node
  console  Open the iroh console
  exec     Run console command(s) & return the output
  get      Fetch data from a ticket
  provide  Create a ticket to share data
  help     Print this message or the help of the given subcommand(s)

Options:
      --rpc-port <RPC_PORT>  RPC port of the Iroh node [default: 4919]
  -h, --help                 Print help
  -V, --version              Print version

Options for start, get, doctor:
      --keylog                       Log SSL pre-master key to file in SSLKEYLOGFILE environment variable
      --metrics-addr <METRICS_ADDR>  Bind address on which to serve Prometheus metrics
      --cfg <CFG>

Concerns

Shorter-lived nodes

The big "concern" here is a trend toward shorter-lived nodes. I'd argue this is a non-issue. I don't think we should be optimizing for nodes to be online for as long as possible. Instead we should be optimizing for nodes to be online exactly as long as they need to be to do meaningful work.

iroh exec puts us on a path to a scripting language

iroh exec is much weaker than the full console, and users will likely ask for things like variables to make iroh exec more powerful. This runs the risk of putting pressure on the iroh team to implement an entire language just to make iroh exec useful.

working with iroh exec should be painful. It's an escape hatch. Users should be directed to use the console, and if that's not enough, well, that's why iroh is an SDK.

[flub]

modify the iroh console command to start iroh node if one is not running, presents a warning to the user with a documentation link

How do you envision this works? I think it would be nice to keep avoiding starting the node in the background, because that opens the doors to "daemonising" which is something that's should no longer happen in-application anymore IMHO.