Thinking about a CLI interface

[whyrusleeping]

# base level necessary things
lotus wallet sign-msg HEXENCODEDMESSAGE
lotus mpool push HEXENCODEDSIGNEDMESSAGE
lotus mpool pending

# calls method on an actor, does not send a message, really only for 'read
# only' things as a way to query chain state
# NOTE: ethereum has an explicit "estimate gas" api. We could also have that, but having this call return a receipt with the gas it would have used might be a nice api
lotus ??? call ADDRESS METHOD PARAMS...

# sends a message to the network invoking the given method with params on the
# specified actor. under the hood, this creates, signs, and pushes a message to
# the network
# To consider: should this block until its included in the chain? (at least multiple minutes)
lotus ??? invoke ADDRESS METHOD PARAMS...

# TODO: wallet commands to create and manage keys (take hardware wallets into account)
# go-filecoin wallet code (by dig) was inspired by ethereum, we should
# investigate, its likely good to use
lotus wallet ??
lotus wallet list
lotus wallet balance ADDRESS

lotus chain head
lotus chain getactor ADDRRESS # shows all actor info, like balance, code cid, state root, ID address and resolved normal address
lotus chain getblock <by height | by hash>
lotus chain getmsg <hash>
lotus chain pushblock <serialized block + cid list> # for a miner to submit a block they made

lotus node status # maybe too general?
# alternatively... just get the specific thing we want
lotus node issyncing
lotus node gasprice

lotus swarm # libp2p funtimes
lotus config # you know the drill

# TODO: Mining api!
# if this is a separate process, it needs an api, if its not, it needs api entries here...
# we want to be able to support multiple different miner actors in a single process
# do we separate block production from proving? if so, how?
lotus-miner status
lotus-miner set-price <miner> <price> # assuming theres only one discriminator for whether or not to accept deals
lotus-miner list-miners
????

Ethereum API for reference: https://github.com/ethereum/wiki/wiki/JSON-RPC
Bitcoin core api: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
Zcash api docs: https://zcash.readthedocs.io/en/latest/rtd_pages/payment_api.html (they extended bitcoins apis a bit to add stuff for sheilded addresses, including a sort of 'background jobs' api for snark proving)

[whyrusleeping]

also need an API to wait for a given message to be included into the chain

[whyrusleeping]

theres also the question of how multisig wallets (which are an actor on-chain) and payment channels should be interacted with. I feel like they should somehow get nicely integrated into the wallet command (at least, the multisig should, the payment channel stuff is harder).

Having a nice API for payment channel payments is really important

[magik6k]

lotus swarm # libp2p funtimes

How about we grout all libp2p related things under net:

lotus net ping Qm...
lotus net connect /ip4/1.2.3.4/... // I'd also like a magical `lotus connect` which could be supplied a miner address and do the resolving, and then this feels a bit redundant..
lotus net dht ...

[magik6k]

lotus chain pushblock <serialized block + cid list> # for a miner to submit a block they made

I feel like this is something that should only live on the RPC API

[whyrusleeping]

I feel like this is something that should only live on the RPC API

Yeah, probably. though i always like being able to do everything both places

[magik6k]

lotus node status # maybe too general?

Or even just lotus status, this command is probably going to be important for good initial UX (even though this is supposed to be a low-level client people will try to interact with it).

$ lotus status
Wallet Address: fABCD (+0 others)
Balance (fABC...): 0.555
Peers: 12 (maybe use colors to indicate a 'healthy' peer count)
Chain: SYNCED (H: 123, B: zBlockCid..) // or tipset, or just height

[dignifiedquire]

bikeshed: lotus info feels more intuitive to me, than status

[dignifiedquire]

if doing nested commands, e.g. lotus <level1> <level2> I would try to minimize commands with only one level. In my experience this makes it much harder to do guesses on where sth lives. For example, say there is lotus status and a lotus node . This will likely lead to users thinking sometimes lotus node statusand sometimeslotus status`. (possible solution, make all top level things aliases for nested ones, so everyone is happy)