Commando (CLN) connector

[kiwiidb]

Alby doest not yet support Core Lightning. Since the latest release of Core LN, the plugin commando is shipped by default with Core Lightning. This plugin is used by the LNSocket package, which allows one to connect from the browser to a Core LN node over an untrusted websocket bridge server. The connection is trustless and e2e-encrypted between the browser and the node. Tor nodes can also easily be supported by this bridge server mechanism. Alby would host the bridge server (we can also use proxy.lnlink.org for development).

Authentication is done using so-called runes, which are like macaroons and can have fine-grained permissions.

We could even expand the webLN methods to support all commando commands, allowing one to execute all possible c-lightning commands from webLN.

[kiwiidb]

FYI: jb55/lnsocket#16

[lnbc1QWFyb24]

@kiwiidb I have created a pure JS version of lnsocket that works nicely in the browser that you can check out here.

[kiwiidb]

@aaronbarnardsound thank you so much, your library is awesome!
It works, and I've started working on an integration in #1577

[lnbc1QWFyb24]

@kiwiidb Sweeeet! Let me know if you run in to any issues, bugs or if you have any feature requests.

[kiwiidb]

@aaronbarnardsound we have run into some issues. See this Loom video for the current status:

https://loom.com/share/8b04e1aa80eb4124b5833cd673f09bae

I would need to look more into detail in the library itself and play around with it more.
It is however quite hard to debug because you don't know what's happening behind the scenes, the websocket messages are all encrypted. I also think I would like to rewrite the proxy in Go (I have deployed https://github.com/jb55/ln-ws-proxy) at wss://lnwsproxy.regtest.getalby.com .

If you are interested in working together on this, we have a bounty for this topic available. Would need to work out the details but it would be in the ballpark of 1M sats.

[lnbc1QWFyb24]

Hey @kiwiidb happy to work with you on this! I have been doing a lot of work getting the commando connection rock solid for an app I am currently working on, and I believe it is in a good spot. Happy to jump on a call with you to help debug at some point as well, but here are some steps you can take in the meantime:

1. Make sure you are on the latest version of lnmessage as I have been releasing a lot of bugfixes as I find them. The current version is 0.0.7
2. I rewrote jb55's ln-ws-proxy server and there were a few changes I needed to make to ensure it is reliable for long running connections. So try running this proxy instead. It is written with uWebsockets.js which apparently has as good if not better performance than go WebSocket servers (I have not verified this myself), so you may not need to rewrite it. Let me know if you have any feedback on that codebase as well.
3. I have not updated the docs on lnmessage yet (will do this week hopefully), but you can add a logger object to the constructor and that will give you much greater insight as to what is going on under the hood:

const connection = new LnMessage({
    remoteNodePublicKey: publicKey,
    wsProxy,
    ip,
    port: port || 9735,
    privateKey: sessionSecret,
    logger: {
      info: console.log,
      warn: console.warn,
      error: console.error
    }
})

Another tricky thing that you may run in to is that when calling long running RPC methods such as waitanyinvoice and waitinvoice is that if you call as expected it can break the decryption in lnmessage until the app is refreshed which breaks all rpc methods. I am not sure if it is a commando bug or not, but the current behaviour is that if you call waitanyinvoice and it is waiting for a payment to be received, and then the connection is dropped, commando does not clean up that call and will return a response as soon as an invoice is paid even if it is a new connection (that has been initiated with particular decryption and encryption parameters).

The solution I have found is to cache the request method and id in local storage before calling, and then on refresh, check if the app has already made the waitanyinvoice call with the same params, if so, then do not make the call again, but just wait for a commando response with the cached reqId. I need to document this as well, but for the moment you can check out how I handle it here.

You can also check out the app to get a feel for the UX of a commando connection.

Let me how you go, and hit me up via email to schedule a call if you'd like as well :)

[ggwilin]

Hello, i have a question @aaronbarnardsound @kiwiidb do you manage to connect your node created in Polar(CLN-Regtest)? i've been trying multiple stuff with no success, alway getting errors

• When using the web extension i always get the same error 'Error: A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received'

• When using local Alby i get 'Websocket connection failed'

I have used multiple workarounds, also saw @aaronbarnardsound guide on: clams-tech/Remote#99 and tried to do something similar, with the clams app i have success, but not with Alby.

I don't really know if im missing something, i have used clams browser app and https://github.com/ShahanaFarooqui/CLN-Commando-Client to test and the connection is successful.

If you have some information on the topic, ill appreciate a lot.

Thanks in advance and superb work on what you are building.

PS: If no one is working on BOLT12, i can start looking at that support.

Update: I managed to use it locally by putting the same port where i have my websocket waiting for commando commands as Websocket Server in the config, i don't know if thats a real solution, but its an advance on understanding the problem.

[lnbc1QWFyb24]

Hey @ggwilin I recently fixed direct connection issues in Lnmessage, so I am not sure if Alby is running the latest (v0.0.19) that includes that fix. So first step when testing the extension locally would be to update that.

Next for connecting directly to a node the options passed to Lnmessage need to not include a wsProxy and must pass a wsProtocol param and in the case of connecting to a local regtest node you'll want to pass in ws::

const connection = new LnMessage({
    remoteNodePublicKey: publicKey,
    wsProtocol: 'ws:',
    ip: 'localhost',
    port: port || 9735,
    privateKey: sessionSecret,
    logger: logger
})

The UI in the Alby extension would need to be modified in the advanced section to allow for a direct connection. This is what the Clams app has in the develop branch at the moment:

Hope that helps!

Bolt12 support for Alby would be dope! We are hopefully going to implement soon in Clams.

[kiwiidb]

@ggwilin what you did seems like the right solution.
@aaronbarnardsound we'll update the dependency.