Thunder CLI UX

[D4nte]

As per 25Aug discussion:

• node and CLI
• Communication CLI<>node: gRPC
• Communication between nodes: libp2p or gRPC
• The purpose of this software is to execute atomic swaps and NOT general channel management.

Note that as we haven't got everything in place for atomic swap, we can start the CLI now and possibly introduce some general channel management commands to have something that works.

UX

Node

# Starts the node in the foreground, it waits for usage of revoked transaction to punish and wait for commands on gRPC interface
thunder
# Starts the node with specified config
thunder --config ./foo/bar 
# Dump the current config
thunder --dump-config

CLI

# connects to another node (whether or not we are using libp2p, having a contact list would make further commands simpler)
thunder-cli connect <peerid[@address]>
# Open a channel and buy (recip. sell) the base asset, specify the additional balance we want to commit to the channel and the one the other party is committing. If both are zero then the only balance is the asset swapped.
thunder-cli open-buy|open-sell <quote asset> <base asset> <peerid> <our additional channel balance> <their additional channel balance> 
# Proceed with a swap, a channel must already be opened with enough fund with the given peer
thunder-cli buy|sell <quote asset> <base asset> <peerid>
# list current active channels, their balances and relevant txids
thunder-cli channels
# list current active and old closed channels, their balances and relevant txids
thunder-cli channels --all
# collaboratively close the given channel (or channel to the given peer, if there is only one channel)
thunder-cli close <channelid|peerid>

Initial post

Re the UX of the CLI for this software.

CLI and daemon with RPC

This software needs to run as a daemon to at least watch the blockchain for revoked transactions being publish.
If such transaction is published then a punishment transaction should be broadcasted.

The preferred way would be to write one daemon, similarly to bitcoind or lnd, that exposes a json rpc or grpc interface (or both) and also write a cli that communicate with said interface.

The issue with that is that we would then need to design said interface (not sure we have time in the given timeframe).

Example

$ thor &
$ thor-cli connect <peerid>
$ thor-cli open <localamount> <remoteamount> <peerid>
$ thor-cli pay <amount> <channelid/peerid>
$ thor-cli close <channelid>

No RPC

Another possibility is for the daemon to simply get the revoked transactions from the database and watch the blockchain for those. It could then punish when it sees one but it is likely to be an issue if it also writes in the DB in concurrence with another call that updates the channel.

We could take the risk for this PoC or simply not write in the DB and just give an alert, providing either a punish command or a update command to update the DB from seen blockchain actions.

Example

$ thor watch & # Start a daemon that reads from the db and punishes
$ thor-cli connect <peerid>
$ thor-cli open <localamount> <remoteamount> <peerid>
$ thor-cli pay <amount> <channelid/peerid>
$ thor-cli close <channelid>
$ pkill thor # Stop watch command
$ thor update # Update DB with any punishment that might have happened.