[bisq-network/events] Upcoming Dev Call "How to proceed with the API cont." (#32)

[Chris Beams]

/cc @blabno, @mrosseel, @m52go 

I won't be able to make the call today, but I've reviewed the minutes from the previous call (#30), and I'd like to offer a few ideas on how we might proceed. Forgive me if any of this has already been discussed elsewhere.

## Introduce `bisqd` and `bisq-cli` binaries

This was briefly mentioned in the minutes of the last call, but I think we'd be wise to follow suit in pretty much every way with how Bitcoin Core does things around its RPC API. As I imagine everyone knows, Bitcoin Core can be run headlessly as a daemon using the `bitcoind` command. This is literally Bitcoin Core without a UI. Running `bitcoind` automatically enables the RPC server, which can be accessed over `localhost:8332` using basic auth with the `-rpcuser` and `-rpcpassword` arguments or falling back to the `rpccookiefile` approach by default.

The `bitcoin-cli` app is essentially a reference client for the RPC server, and `bisq-cli` would serve the same function:

```
$ bitcoin-cli --help | head
Bitcoin Core RPC client version v0.18.0.0-g2472733a24a9364e4c6233ccd04166a26a68cc65

Usage:  bitcoin-cli [options] <command> [params]  Send command to Bitcoin Core
or:     bitcoin-cli [options] -named <command> [name=value]...  Send command to Bitcoin Core (with named arguments)
or:     bitcoin-cli [options] help                List commands
or:     bitcoin-cli [options] help <command>      Get help for a command
```

```
$ bisq-cli --help | head
Bitcoin Core RPC client version v1.1.7

...
```

There is more to discuss about the exact form that `bisq-cli` would take, and I can share more detailed ideas later, but the point I want to make here is that rather than just exposing an API, I believe we should expose a reference client for it as well (beyond just tests in the main codebase).

It is very satisfying to interact with bitcoind (and lnd / c-lightning, etc) in this way, to play around with json results, pipe them to `jq`, whatever, possibly even just scripting the cli to do what you need, and of course using it as a reference when building your own app/bot in your language of choice. This approach of daemon and cli client is a pretty standard unix convention, and has been widely adopted by the LNP/BP community so far, I don't see why we shouldn't follow suit.

Note that these binaries get installed with whatever package manager is involved. For example, if you just want to install Bitcoin Core and run the GUI, you would (on a Mac) run `brew cask install bitcoin`, and if you wanted the daemon and cli utilities, you would run `brew install bitcoin` to get them. We could set things up similarly, again following existing conventions.


## Release small increments of API functionality on an as-needed basis

I know a lot of work has been done on a pretty comprehensive REST API, but I'd like to suggest that we start very small in terms of actually releasing anything. That we do what's necessary to bisq-core to be able to run it headlessly, i.e. as a daemon, and that we implement only as much API surface area to satisfy one or two discrete use cases. For example, getting the balance of your bisq wallet might look something like the following:

```
$ bisq-cli getbalance
{
    available: 0.12345678
    reserved: 0.00000000
    locked: 0.00000000
}
```

How the actual API is called, e.g. RESTfully via a GET request to a /wallet/ endpoint, via a POST to a JSON-RPC endpoint (as Bitcoin Core does it) or via gRPC (as lnd does, alongside their alternative REST API) is something that can be discussed further (and is indeed being discussed on these calls). My point here is that I think it would be best to evolve the API around with the `bisq-cli` client taking a first-class role. That as we develop new API functionality, we always update the to be able to take advantage of it. That way devs and users alike can easily get hands-on with it and play around without having to make actual programmatic HTTP calls, etc.

Another early use case beyond the obvious and simplistic `getbalance` above, could be a `placeoffer` or `takeoffer` call. These seem to me to be obvious functionality that anyone wanting to script Bisq interactions would need at a minimum, i.e. everything else could be done via the GUI.

This is a rather incomplete overview of what I have in mind, but I wanted to get something put together in time for the call, and I'm already a few minutes late for that. Thanks for your consideration!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/events/issues/32#issuecomment-532153973
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20190917/8a3d0d3e/attachment-0001.html>