we need a python module

[AndySchroder]

Currently lightning node connect is written in go and compiled to web assembly for use in https://github.com/lightninglabs/lnc-web within a browser using javascript. Initially, I thought that maybe web assembly was the most universal way to use lightning node connect, so I tried to use web assembly from python with wasmer. In #70 I mention that I can't get it to work with wasmer.

Later, I learned that Zeus uses https://github.com/lightninglabs/lnc-rn which has the go code compiled to native binaries for mobile (lightninglabs/lnc-rn#23) and does not use web assembly.

Now, I'm wondering, would it be simpler to make a python module that uses natively compiled go code instead of using web assembly code within python? Here are some relevant resources

• https://github.com/go-python/gopy
• https://words.filippo.io/building-python-modules-with-go-1-5/
• https://github.com/ardanlabs/python-go/tree/master/grpc

With the new LND Accounts feature (lightninglabs/lightning-terminal#363 , https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/accounts) that leverages Lightning Node Connect, it's critical that there are more ways to use Lightning Node Connect in a variety of code bases. The LND Accounts feature can safely and easily allow a wide variety of applications and machine to machine devices to use the lightning network.

[guggero]

While I definitely see and understand your issue, I don't think we should start adding language specific modules to this repository. Otherwise we'll end up needing to maintain such modules for a whole list of languages.

I believe WASM should be the common ground as there seem to be WASM interpreters out there for most languages. So we should instead focus on making sure the generated WASM binary can be used with tools such as wasmer. I'm going to comment in your other issue about it.

If you want to create and maintain a Python module outside of this repository, then by all means go ahead. We'll probably even link to it.

[AndySchroder]

While I definitely see and understand your issue, I don't think we should start adding language specific modules to this repository. Otherwise we'll end up needing to maintain such modules for a whole list of languages.

I can see that the python package itself should be a separate repository like https://github.com/lightninglabs/lnc-rn, but in the Makefile here you have apple/ios/macos/android binary builders. That's the only reason I suggested it here. I thought maybe the Makefile would have the necessary options added to build the binary file for the python package.

For fun, I did just try gopy to see what it it would do and am getting stumped with the following error:

root@44183a01694f:/lightning-node-connect# gopy build -output=out -vm=python3 -build-tags="appengine autopilotrpc chainrpc invoicesrpc neutrinorpc peersrpc signrpc wtclientrpc watchtowerrpc routerrpc walletrpc verrpc" github.com/lightninglabs/lightning-node-connect/...
gopy: skipping 'main' package "github.com/lightninglabs/lightning-node-connect"
2023/02/20 12:03:41 error dispatching command: gopy: skipping 'main' package "github.com/lightninglabs/lightning-node-connect"

[Roasbeef]

For fun, I did just try gopy to see what it it would do and am getting stumped with the following error:

That looks fine, it's just skipping the top level main package.

I think what we need to do is extract some of this, into something more easily useable as a module: https://github.com/lightninglabs/lightning-node-connect/blob/master/cmd/wasm-client/main.go. Most of the stuff needed to connect a client lives here: https://github.com/lightninglabs/lightning-node-connect/tree/master/mailbox.

On the upside, WASI build targets are nearly done for Go: golang/go#58141. Tiny Go is also looking to target the new build target directly: tinygo-org/tinygo#3685

[Kukks]

For fun, I did just try gopy to see what it it would do and am getting stumped with the following error:

That looks fine, it's just skipping the top level main package.

I think what we need to do is extract some of this, into something more easily useable as a module: master/cmd/wasm-client/main.go. Most of the stuff needed to connect a client lives here: master/mailbox.

On the upside, WASI build targets are nearly done for Go: golang/go#58141. Tiny Go is also looking to target the new build target directly: tinygo-org/tinygo#3685

Hi @Roasbeef. Both PRs linked were merged, indicating that a WASI build of LNC should be possible. This would be great as I can potentially add it as an option as a BTCPay Server Lightning node backend as per btcpayserver/btcpayserver#4859 and btcpayserver/btcpayserver#5626.

I briefly tried to modify the wasm make action to see if it was trivial (I have absolutely no go knowledge so it might actually still be trivial) but got the following: package github.com/lightninglabs/lightning-node-connect/cmd/wasm-client: build constraints exclude all Go files in /home/runner/work/lightning-node-connect/lightning-node-connect/cmd/wasm-client

wasi step (just changed GOOS to wasip1):

	cd cmd/wasm-client; CGO_ENABLED=0 GOOS=wasip1 GOARCH=wasm go build -trimpath -ldflags="$(LDFLAGS)" -tags="$(RPC_TAGS)" -v -o wasm-client.wasi .
	$(CP) cmd/wasm-client/wasm-client.wasi example/wasm-client.wasi

[ViktorTigerstrom]

Hey @Kukks!

Awesome, it would be really nice if you'd be able to add LNC support for BTCPay Server Lightning node backends 🎉!

I briefly tried to modify the wasm make action to see if it was trivial (I have absolutely no go knowledge so it might actually still be trivial) but got the following: package github.com/lightninglabs/lightning-node-connect/cmd/wasm-client: build constraints exclude all Go files in /home/runner/work/lightning-node-connect/lightning-node-connect/cmd/wasm-client

The error your seeing is due to that the files in the cmd/wasm-client includes the //go:build js build constraint. Unfortunately though, it's not as easy as just changing the build constraints in the files, as the package relies quite heavily on the syscall/js dependency. I'll look into what would be required for us to add support for a WASI build, as I agree that such support would be really useful!

[huumn]

@Kukks @AndySchroder would compiling this into a daemon work for your use cases (lncd)? It'd keep the connection(s) to the mailbox and expose a grpc/rest interface.

We are thinking about doing this for SN's backend which needs:

• multitenancy
• a simple way to make sure we only have one connection per pairing phrase across several application servers

Also, more just preferentially, we'd prefer to avoid loading wasm on the application server.