Running lightning-charge on top of lnd/lncli

[elementsproject]

Running lightning-charge on top of lnd/lncli

[kikoncuo]

I can work on this, got a pretty clear idea on how the client is used, I need to create a new connection for LND and wrap the calls so they have the same names.

1. Flag to specify LND and provide needed params
2. Create client connecting to RPC through port and macaroons
3. Identify all calls to the client (Named ln on code)
4. Create wrappers for those calls into LND
5. Tests

I'll work on a simplified fork from this library, which is similar to the current client (lightning-client-js).
I won't use the current one because the access to the client is completely different and heavily designed for specific behaviours from lightningd

@shesek I've found that the client is only used on the following files, can you confirm? Thanks!
app.js, model.js (invoice uses lnconf which is taken from ln but it's not used right now)

[shesek]

Is there a way of running the lightning-charge API on top of lightningnetwork/lnd?
Are there already projects out there trying this?

It's currently not possible and afaik not being worked on, but is something that might be added to Charge in a future release.

Is the REST API described in the README stable or are there still a lot of changes?

It is considered stable. There might be slight changes, but considerations are made to retain backward compatibility and the introduction of incompatible changes will be communicated clearly and result in appropriate semver version bump.

What events does the WebSocket API support?

The WebSocket API currently provides a single event type, for incoming payments. It is simply a message with the invoice JSON as the body. This might be extended in the future for additional event types.

Do you think the current test coverage is enough to run other ElementsProjects like e.g. nanopos on top of a compatible REST API or are they using a lot of undocumented stuff?

The main thing that isn't part of the test coverage (nor is documented very well) is the built-in checkout page that's used by nanopos (via redirection) and Lightning Publisher (via an iframe).

Other than that, I would say that the test coverage for the HTTP REST API is quite complete, minus testing for some edge cases etc.

I was looking into it and got it working.

@parth-choudhary that doesn't seem like it should actually be working... lnd has an entirely different rpc from c-lightning, Lightning Charge won't be able to use that even if you get them to connect.

[shesek]

@mojoaxel I noticed another untested feature: POST /invoice can accept a webhook parameter directly, rather than adding it via POST /invoice/:inv/webhook. I created #39 to keep track of this.

[parth-choudhary]

I was looking into it and got it working.

All you need to do is, create a domain socket which listens to lnd node. Since Lightning Charge uses domain socket to connect. There can be a number of ways to do that, I used socat

The command to connect create a domain socket using socat is:
socat -d -d UNIX-LISTEN:/somepath/lightning-rpc,fork OPENSSL:0.0.0.0:8001,verify=0

This is assuming LND is listening on port 8001.

Now start lightning charge using:
charged -l /somepath/ --api-token mySecretToken

And Voila

[parth-choudhary]

This is assuming you have installed LND certificates using openssl. :)

[parth-choudhary]

That's true, I got them to connect and only rpc calls that they both have same are callable like getinfo, getbalance etc.

[mojoaxel]

Thanks for all your answers!
I think it would be great if we could provide some interoperability in the future.