Lightning Node Connect does not work with wasmer

[AndySchroder]

Lightning Node Connect does not work with wasmer (https://wasmer.io/). Here is the output from the standalone wasmer application.

root@44183a01694f:/# wasmer run lnc-v0.2.3-alpha.wasm 
error: failed to run `lnc-v0.2.3-alpha.wasm`
╰─▶ 1: Error while importing "go"."debug": unknown import. Expected Function(FunctionType { params: [I32], results: [] })
root@44183a01694f:/# 

I'm actually trying to use https://github.com/wasmerio/wasmer-python , and am getting the same error, but I show the error above using the standalone version of wasmer because it's the easiest to reproduce and I expect the same error happens no matter what language interface you are trying to use.

Given the number of programming languages wasmer supports, it seems like it would be ideal for Lightning Node Connect to work in wasmer because it avoids the need to re-implement Lightning Node Connect in every programming language. https://lightning.engineering/posts/2021-11-30-lightning-node-connect-deep-dive/ suggests that a bLIP is coming for Lightning Node Connect, but I have not seen it yet. The existing documentation found at https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/lightning-node-connect , https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/lnc-npm , and https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/mailbox is high level and not in the form of a spec that I feel like I could re-implement it all natively in python. Although a spec would be nice, the next best thing would be some code that we can easily embed in any programming language.

[AndySchroder]

More info:

root@44183a01694f:/# wasmer inspect lnc-v0.2.3-alpha.wasm 
Type: wasm
Size: 53.9 MB
Imports:
  Functions:
    "go"."debug": [I32] -> []
    "go"."runtime.resetMemoryDataView": [I32] -> []
    "go"."runtime.wasmExit": [I32] -> []
    "go"."runtime.wasmWrite": [I32] -> []
    "go"."runtime.nanotime1": [I32] -> []
    "go"."runtime.walltime": [I32] -> []
    "go"."runtime.scheduleTimeoutEvent": [I32] -> []
    "go"."runtime.clearTimeoutEvent": [I32] -> []
    "go"."runtime.getRandomData": [I32] -> []
    "go"."syscall/js.finalizeRef": [I32] -> []
    "go"."syscall/js.stringVal": [I32] -> []
    "go"."syscall/js.valueGet": [I32] -> []
    "go"."syscall/js.valueSet": [I32] -> []
    "go"."syscall/js.valueDelete": [I32] -> []
    "go"."syscall/js.valueIndex": [I32] -> []
    "go"."syscall/js.valueSetIndex": [I32] -> []
    "go"."syscall/js.valueCall": [I32] -> []
    "go"."syscall/js.valueInvoke": [I32] -> []
    "go"."syscall/js.valueNew": [I32] -> []
    "go"."syscall/js.valueLength": [I32] -> []
    "go"."syscall/js.valuePrepareString": [I32] -> []
    "go"."syscall/js.valueLoadString": [I32] -> []
    "go"."syscall/js.valueInstanceOf": [I32] -> []
    "go"."syscall/js.copyBytesToGo": [I32] -> []
    "go"."syscall/js.copyBytesToJS": [I32] -> []
  Memories:
  Tables:
  Globals:
Exports:
  Functions:
    "run": [I32, I32] -> []
    "resume": [] -> []
    "getsp": [] -> [I32]
  Memories:
    "mem": not shared (636 pages..)
  Tables:
  Globals:
root@44183a01694f:/# 
root@44183a01694f:/# wasmer validate lnc-v0.2.3-alpha.wasm 
Validation passed for `lnc-v0.2.3-alpha.wasm`.
root@44183a01694f:/# 

[guggero]

Thank you for the report!

I took a quick look at wasmer and a few google searches around the error message. It looks to me like Golang's WASM support mainly targets a browser/DOM environment, which isn't ideal. But perhaps with the use of tinygo we could create a WASM binary that's wasmer compatible.

I'll see if I can find some time to investigate what's needed to get this library compiled with TinyGo.

suggests that a bLIP is coming for Lightning Node Connect

Yes, that's correct, and that's still on our TODO list. Resources are spread a bit thin around LNC at the moment, but we definitely want to get that bLIP out soon.

[Roasbeef]

Related-ish issue: https://github.com/golang/go/issues/58141

[Roasbeef]

Yeah it looks like wasmer is basically a specific wasm runtime, looks like there's a Go library to create/interact with wasm blobs compiled for that runtime: https://github.com/wasmerio/wasmer-go

[Roasbeef]

Here's another wasm runtime (based on WASi related to that go stdlib issue above): https://wazero.io/

[Roasbeef]

Also re the bLIP: we want to make sure things are stable-ish (eg we changed up the handshake) before committing to a public standard for it. Developing as is now, we can be a bit more nimble, as we're also developing against a clear use case as well.

[AndySchroder]

Also re the bLIP: we want to make sure things are stable-ish (eg we changed up the handshake) before committing to a public standard for it. Developing as is now, we can be a bit more nimble, as we're also developing against a clear use case as well.

I'm okay not having a bLIP right now if I can use the wasm in other programing languages.

[AndySchroder]

Yes, wasmer-go is a counterpart to wasmer-python. However, if you already have your code written in go, there is no need for that, other than you may be able to do easier debugging that would allow any wasmer interface to finally work. Similar comment about wazero.

wasmer does have some infrastructure related to wasi, but I don't understand what wasi is yet.

• https://github.com/wasienv/wasienv
• https://docs.wasmer.io/integrations/js/wasi
• https://github.com/WebAssembly/WASI