Probably a simple matter of importing the eclair jars and invoking Setup.boot to get a new "Kit" API.

see: line 101 https://github.com/ACINQ/eclair/blob/6142d92cc189dbc63f4118e349f5bcd30349e565/eclair-core/src/test/scala/fr/acinq/eclair/integration/IntegrationSpec.scala

from proposals.

Because BISQ nodes are long running, my proposal starts at lower level architecture which will allow BISQ to escape the desktop.

This is a CLIENT <-> SERVER model, where the server is wholly owned and managed by the human trader (ie. one server per client). They can access their BISQ functionality from anywhere, on any device.

Applicable to WWW, this could also be true for LAN and DESKTOP alternate scenarios.

Top level summary

• The BISQ GUI (Graphic User Interface) is statically served (templates and logic) over http/s.

• All data is bidirectionally transferred over encrypted websocket (RFC 6455).

• Bisq-api/exchange becomes part of an API driven stack of modules, which will include ECLAIR (which has its own JSON-RPC interface)

• All communication is routed through an API manager, which serves to translate all the various module API's into a common standard, thus allowing standardised communication within the stack:

  • Module <-> Module
  • Client <-> Module
  • Module <-> Client
  • Module -> Module <-> Client
  • Etc.

• BISQ exchange development can focus on a reduced scope, while modular development around it can independently grow in resources and community, providing valuable functionality for exchange to leverage.

Topology diagram

Proof of concept

I have a POC for the above typology here: https://github.com/citkane/bisq-front
It can be installed locally and run on REGTEST.
I am working with @mrosseel to resolve and test https://github.com/mrosseel/bisq-api/issues/13, after which I will publish URL's for BOB and ALICE that anybody can play with in their browsers.

Eclair Integration

Given the above typology, it becomes trivial to launch an instance of Eclair with JAVA. This will be exactly the same as launching BISQ. BISQ will be able to talk to Eclair bi-directionally through the API manager.

Equally trivial will be launching the required (by Eclair) Bitcoind. This is however not practical, as it forces every BISQ node to also be a full Bitcoin node with a full blockchain. This will only become practical once Neutrino, a (preferred by ACINQ) Bitcoin Light Client, matures sufficiently.

Envisaged development pattern

1. Eclair silently runs as a Lightning node
2. Api management is built for Eclair
3. GUI is built for a standalone Lighting wallet within BISQ
4. BISQ now has all the required tools in it's shed to allow EXCHANGE developers to integrate Lightning into trading logic.

from proposals.

The proof of concept is now live at:
http://bob.openpoint.ie/
http://alice.openpoint.ie/

from proposals.

Closing as inactive. This got a lot of 👍's but ultimately no discrete proposal was offered for how to integrate Eclair within Bisq as it is today. If someone would like to re-open this or, perhaps preferably, to open a new proposal about this, please do. It's worth noting here that @ACINQ just shipped their first mainnet-ready Eclair release.

And in case someone does re-open this (or open a new proposal), please see the guidance on proposals I've just put together in #11. The goal of a proposal around integrating Eclair would be to put together a brutally minimal approach to running a lightning node within the same process as a running Bisq node, for the purpose of (a) earning fees and (b) generally supporting the Lightning network. Any such integration should be bare-bones to start with. Indeed that's exactly what we're looking for in such a proposal: what is the simplest integration that could possibly work for making a Bisq node serve double-duty as a Lightning node?

from proposals.

3 years passed since this proposal, maybe there is some new solution that would easily allow to run BISQ with Lightning Network?

from proposals.