WASM

[hydra-yse]

Tracking issue for WASM integration on the Nodeless SDK.

Progress branch: wasm

Compilation Issues

Currently, these are the crates that prevent building for wasm32-unknown-unknown target:

• electrum-client
• boltz-client - Can add a feature flag to use reqwest's blocking client, which is wasm-compatible
• tokio-tungstenite
• tonic
• sdk-common - After BIP353, we utilize hickory-resolver for DNS queries. This should be locked behind a feature flag
• rusqlite (is able to compile, but requires work-arounds in order to work in the browser)

Creating an SDK WASM wrapper

Taking inspiration from lwk's lwk_wasm crate, we can create a wrapper for the primary SDK methods while also communicating with the browser API via the web-sys crate. This will allow us to instatiate WebSockets/gRPC connections and then forward the responses to the handlers (which will require to expose the interface methods to handle the message stream).

This is especially useful in the case of the following dependencies: electrum-client, tokio-tungstenite and tonic, which affect the following parts of the SDK:

• Liquid/Bitcoin chain service
• Swapper
• Swapper status stream
• Real-time sync service

References

• lwk_wasm
• wasm_bindgen guide
• WASM WebSockets in Rust

[dangeross]

Not too much to do then! 😅

I would suggest splitting it up into two projects; sdk-common and nodeless core. The breez server has a grpc web proxy which should help.

The great thing about having rt-sync now is we don't have to rely on file storage for rusqlite. We could start with in memory only and work from there.

The rust-nostr repo is another good example of integrating wasm. In there they have configurable persistence modules depending on the integration.

[roeierez]

@hydra-yse before adding javascript wrappers code I think we should break down the compilation issue into several tasks. I am thinking of the following:

• in-memory rusqlite
• tonic/tokio dependencies
• boltz client to be wasm compatible
• electrum client?

electrum client is tricky and not sure if possible as is. I think lwk_wasm uses esplora API instead but this is not a good solution as it doesn't have batching API.
Perhaps the task here is to more to https://github.com/RCasatta/waterfalls ?

[hydra-yse]

Here's the division in issues that I've thought of:

• Add option for in-memory persister
• Expose and proxy sync service handlers
• Expose Boltz status stream handler
• Make Boltz client WASM-compatible (should already be out of the box)
• Pass external chain provider to LWK (using waterfalls)
• Ignore Electrum client in chain services
• Lock BIP353 logic behind feature flag in SDK-common (or separate the crate, as per @dangeross suggestion)

tokio itself is compatible against wasm32-unknown-unknown with the current dependencies, so it's not an issue.

Note that these tasks do require to start working on the wrapper at the same time (not a JS wrapper, but a Rust wrapper). It's going to be a submodule of the repository, probably under lib/wasm, which includes:

1. All the specific SDK setup mentioned above (e.g. instantiating the SDK with in-memory persister)
2. The web-sys setup, so that users don't need to manually implement the WebSocket forwarding logic etc.

Not sure we'll need a JS wrapper later on, perhaps just a shim for type definitions. See wasm-pack for more info