[bisq-network/proposals] Use a GRPC API as core API and use wrappers around for other API types (#136)

[Chris Beams]

> I will not have time to continue to work on [gRPC support] so anyone who is interested is welcome to take over...

I'll pick up on this, as I have some bandwidth for it now. I'll take the changes that @chimp1984 has made in his `grpc` branch and will iterate on it in my own fork. With what follows below in mind, I think we can close this proposal and move forward.

I plan to deliver this work in a series of small-as-possible PRs that get merged to master and released with each upcoming minor version. Each PR will include complete, usable functionality, e.g.:

 - support for running Bisq as a daemon with the gRPC service enabled using `--daemon`
 - support for running Bisq as a desktop ui with the gRPC service enabled using `--rpcserver`
 - support for a few simple commands such as `getversion` and `getbalance`
 - support for conveniently exercising these commands using a new `bisq-cli` client utility

All of the above might constitute the first PR. Then, with this foundation in place, we can iterate on more involved commands to get to a level of coverage where a real trading bot can be developed. I intend to design and stub out such a bot and gradually replace the stubs with real RPC calls as they are implemented until the bot actually works end-to-end. Once that's done, the template should be set and it should be straightforward for anyone to follow convention to contribute new commands on an as-needed basis.

If we can manage to release incrementally as described above, it'll be good for getting users engaged. With each Bisq release, they'll have new API goodies to play with, and will be able to explore them easily with the `bisq-cli` client. It should be fun and exciting for (dev) users to watch it evolve, and will likely solicit good feedback from folks with real-world needs for a Bisq API. We can make a little noise about it with each release, e.g. via Twitter (/cc @bisq-network/twitter-admins). I imagine if we do so, certain podcasts and news outlets will pick up on it and help get the word out.

> Whats mainly missing is an authentication mechanism

I haven't looked deeply enough into this to get into specifics here, but generally the goal will be to implement a basic username/password auth scheme modeled after Bitcoin Core. We can also look at implementing IP restrictions and hands-free cookie auth just as Core does too. From the little bit of looking I've done so far, [gRPC does not provide out of the box basic auth](https://stackoverflow.com/a/49657885), but [it has the hooks necessary](https://grpc.io/docs/guides/auth/#extending-grpc-to-support-other-authentication-mechanisms) to implement it on our own. It's also worth noting that [LND's gRPC API authentication is managed using TLS and macaroons](https://api.lightning.community/#lnd-grpc-api-reference). I have no experience with the latter, but have heard good things. Macaroons may be overkill for our needs, but if anyone wants to dig deeper (or already knows them well) it would be worth discussing whether they might be a good option for Bisq. You can read up on the original Google Research paper [here](https://ai.google/research/pubs/pub41892), there's a Java implementation [here](https://github.com/nitram509/jmacaroons) and an online macaroons playground [here](http://macaroons.io/).

As for communication, I propose we rename the existing Keybase `#api` channel to `#rest-api` and create a new channel named `#grpc-api` where we can focus on the work described above. (I've just created the latter now, feel free to join).

Feedback welcome. At a minimum, please react with a 👍 (or otherwise) on this comment if you've taken the time to read this far. Let's get this proposal closed and I'll get to work!

-- 
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/proposals/issues/136#issuecomment-554443705
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191115/ddf47882/attachment-0001.html>