Closed freimair closed 5 years ago
Recording published here:
https://youtu.be/fj34pYDD3B0
EDIT: obviously cannot post a recording of a call that hasn't happened yet. Will post proper link when it's ready.
@m52go I believe this recording (https://github.com/bisq-network/events/issues/32#issuecomment-529534197) is from the previous session.
/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.
bisqd
and bisq-cli
binariesThis 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.
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!
Recording published here: https://youtu.be/Lu_RKkxdDUE
FYI: bisq.core.app.BisqHeadlessAppMain
is a headless bisq app which can be used for api. Was used in the API branch and the grpc demo.
Here is a re-activated grpc demo: https://github.com/chimp1984/bisq/tree/grpc There is some gradle setup still not correct to get all correctly working, but some dev with more gradle/grpc experience will be able to fix it.
please make yourself familiar with the minutes of #30, we are going to start right where we left off.
[x] how to proceed
[x] how to proceed cont.
Recording
https://youtu.be/Lu_RKkxdDUE