<h2>How to run the code for this proposal</h2>
<p>Here's a quick primer on how to sync up to these changes and exercise the fledgling gRPC API for yourself (<a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=54558767" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/chimp1984">@chimp1984</a>, I'm not sure if this was written down elsewhere; I couldn't find it if so).</p>
<h3>At the command line</h3>
<pre><code>cd $YOUR_LOCAL_BISQ_CLONE
git remote add chimp1984  # this shortcut syntax assumes you have `hub` installed
git fetch chimp1984
git checkout grpc
./gradlew build
./bisq-desktop --appName=Bisq-grpc-demo --desktopWithGrpcApi=true
idea .  # open the project in IDEA
</code></pre>
<h3>In IDEA</h3>
<ul>
<li>Open <code>BisqGrpcClient</code> and run its <code>main</code> method</li>
<li>Type <code>getVersion</code> into the console, notice that <code>1.2.3</code> is returned</li>
<li>Type <code>getBalance</code> into the console, notice that <code>0.00</code> is returned</li>
<li>See the <code>switch</code> statement in <code>BisqGrpcClient</code> for all supported commands</li>
</ul>
<h2>Proposal feedback</h2>
<p>I think the proposal makes sense. Having a 'core' RPC API on top of which any further API (RESTful HTTP, JSON-RPC, etc) can be layered seems workable, and is actually what I originally suggested way back in this <a href="https://docs.google.com/presentation/d/1296AcVUqaPgjbtUMpLBDAwoYxjmOPEtSLLPJhCwtE9Y/edit#slide=id.g34bd40372f_2_2" rel="nofollow">March 2018 slide deck</a>.</p>
<p>I don't have much to say about the implementation as I haven't spent enough time looking at and thinking about it. From a UX perspective, though, I'd like to see the following:</p>
<ol>
<li>
<p>a <code>--daemon</code> option to the main (bisq-desktop) binary that allows it to run headlessly with the core (gRPC) API enabled. So passing <code>--daemon</code> would imply passing <code>--desktopWithGrpcApi=true</code> and would suppress the UI. This is consistent with running the Bitcoin Core desktop client with <code>--daemon</code> enabled in order to run it in the background without launching the UI at all.</p>
</li>
<li>
<p>Ideally, we would ship a <code>bisqd</code> shell script that implies <code>--daemon</code> as well (just as Bitcoin Core ships with a <code>bitcoind</code> binary), but it's not strictly necessary for getting started.</p>
</li>
<li>
<p>The <code>--desktopWithGrpcAPI</code> option should be renamed to <code>--server</code> or <code>--rpcserver</code>. This is consistent with the way you can run the Bitcoin Core desktop client with <code>--server</code> in order to enable its JSON-RPC server while also launching the UI.</p>
</li>
</ol>
<p>With the <code>--daemon</code> and <code>--server</code> options in place, any external gRPC client can be written to exercise the API and as suggested in <a class="issue-link js-issue-link" data-error-text="Failed to load issue title" data-id="491135480" data-permission-text="Issue title is private" data-url="https://github.com/bisq-network/events/issues/32" data-hovercard-type="issue" data-hovercard-url="/bisq-network/events/issues/32/hovercard?comment_id=532153973&comment_type=issue_comment" href="https://github.com/bisq-network/events/issues/32#issuecomment-532153973">bisq-network/events#32 (comment)</a>, I'd like to see us ship a <code>bisq-cli</code> utility for convenient access to the API and to serve as a reference client how to program against it. It could start out by talking gRPC directly, and if we grow a JSON-RPC API down the road, it could perhaps be ported to that, as I think it's what many people writing, say, a trading bot would want to use and have a reference for.</p>
<blockquote>
<p>There is still the question open if we should have 2 desktop modules (one without API and one with API embedded) to don't add those dependencies to all Bisq users even if the API is not enabled.</p>
</blockquote>
<p>Agreed, NACK on having 2 desktop clients. The proposed core API would be just that: quite core to the project. It would be terrible UX to have to ship and explain two clients, and I see no significant threat in adding these minimal dependencies into the mix.</p>
<p>Thanks for putting this together, <a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=54558767" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/chimp1984">@chimp1984</a>!</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/bisq-network/proposals/issues/136?email_source=notifications&email_token=AJFFTNSM26NSOFAPYF73THDQTGUYNA5CNFSM4JLOLQJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDXZUGY#issuecomment-552573467">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AJFFTNRR35CGBUJXYJXQEQTQTGUYNANCNFSM4JLOLQJQ">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AJFFTNQFYTPZ6M6Z4CKZVB3QTGUYNA5CNFSM4JLOLQJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDXZUGY.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/bisq-network/proposals/issues/136?email_source=notifications\u0026email_token=AJFFTNSM26NSOFAPYF73THDQTGUYNA5CNFSM4JLOLQJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDXZUGY#issuecomment-552573467",
"url": "https://github.com/bisq-network/proposals/issues/136?email_source=notifications\u0026email_token=AJFFTNSM26NSOFAPYF73THDQTGUYNA5CNFSM4JLOLQJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDXZUGY#issuecomment-552573467",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>