Support WASM

[danielgranhao]

At Breez, we are interested in supporting WASM in the Nodeless SDK. The SDK depends on boltz-rust, which isn't compatible right now due to dependencies on:

• ureq to access Boltz API
• electrum-client for accessing blockchain data
• tungstenite for the WebSocket status stream
• secp256k1-zkp

We’d like to discuss possible approaches to enable WASM support while keeping the existing functionality intact.

Potential solutions:

• Accessing Boltz API
  • Solution can be as simple as switching to reqwest. It implements WASM support by simply mapping requests to the browser's fetch API. We could switch to reqwest or allow the selection of the http client through features.
• Access to blockchain data
  • This seems like the most challenging part. One option is for the crate to offload communication to the client. An alternative is to add esplora as a possible backend since it's based on http.
• Status stream
  • There are several crates that could be used for websockets on WASM. gloo-net seems like a good option.
• secp256k1-zkp
  • The fix here is simple and can be applied directly on the fork currently in use. Just needs the changes from this PR and from this commit.

Would love to hear your thoughts on these approaches to see if we can proceed with the corresponding contributions.

[danielgranhao]

To support WASM, the crate's API will need to become async due to the browser being natively async. AFAICT there is no good way of bridging it to the current (blocking) interface. Is there a known, specific need for a blocking interface from existing users of boltz-rust? If there is, one solution might be to offer a separate blocking version (similar to reqwest).

[michael1011]

Why would it have to be async? You can WASM bind blocking functions just fine: https://github.com/BoltzExchange/bolt12-wasm/blob/master/src/lib.rs#L28

[danielgranhao]

The issue isn't exposing binds for blocking functions. It's about using the browser's fetch API to make HTTP requests.

[michael1011]

Yes, everything network related will have to be made async, which I thought was implied by your suggestion to switch from ureq to reqwest. I am fine with that, but what about the Dart bindings @i5hi?

[i5hi]

async should not be an issue for the dart bindings.

[i5hi]

Regarding secp256k1-zkp, we are currently using a specific branch for Musig* structures:

secp256k1-zkp = {git = "https://github.com/BlockstreamResearch/rust-secp256k1-zkp.git", rev = "60e631c24588a0c9e271badd61959294848c665d"}

Not sure if this has been merged yet.

[i5hi]

Regarding Access to Blockchain data - we can indeed separate all electrum calls from the core methods. Rather than offloading to the client we can move it to a separate file under a feature and let it return the specific types required by the core swap methods.

[i5hi]

Changing the the websocket server is not an issue at all.

[michael1011]

Regarding secp256k1-zkp, we are currently using a specific branch for Musig* structures:
Not sure if this has been merged yet.

@danielgranhao could you try to upstream your changes to secp256k1-zkp? I would like to avoid having to maintain a fork where we cherry pick the changes we need

[danielgranhao]

@i5hi @michael1011 Thank you for your comments. #91 is ready for review