WASM support

[mriise]

This issue is an attempt to gather information relating to WASM support for rust-libp2p as well as serve as somewhat of a tracking / discussion issue.

Transports

The general approach that we've been taking for transports it to use the web-sys bindings and code against those directly. This allows us to stay in Rust land without having to write any JS. Additionally, the acceptance criteria for any further transport is that they are integrated in the interop-test suite.

Testing

We have additional tests that go beyond the interop suite in the wasm-tests directory: https://github.com/libp2p/rust-libp2p/tree/master/wasm-tests

---

- [x] https://github.com/libp2p/rust-libp2p/pull/4015
- [x] https://github.com/libp2p/rust-libp2p/pull/4248
- [ ] https://github.com/libp2p/rust-libp2p/issues/3611
- [ ] https://github.com/libp2p/rust-libp2p/issues/4389
- [ ] Remove `libp2p-wasm-ext` in the next breaking release
- [ ] https://github.com/libp2p/rust-libp2p/issues/4509

Previous Implementations of WASM libp2p

• https://github.com/paritytech/smoldot
• https://github.com/iotaledger/identity.rs
• https://github.com/sireliah/wasm-p2p-experiment

[mriise]

Pinging people that have previously worked on WASM here (that I know of) @wngr @tomaka @expenses

Also pinging @mxinden

Again, feel free to make suggestions or LMK if I missed anything that should be included!

[olanod]

A different kind of WASM support I'd like to bring to the table and something I'd like to experiment in the coming months(ideas and help will be welcomed) is the definition of a WASI interface that can be proposed later as wasi-p2p or something like that. Is a slightly different kind of WASM integration as the current direction is to be able to compile rust-libp2p to WASM expecting the host to provide calls that abstract the transport like using WebRTC with a set of custom host calls or perhaps the more standardized approach of targeting WASI that will have the sockets abstraction(could/will be polyfilled in the browser).

The proposal I mention is not so much for the browser support or environments that usually run a single bigger WASM blob where libp2p is included, my use case is embedded hardware where I want to allow a very constrained device to run a lightweight WASM interpreter like WASM3 and run many plugins that need to be as lightweight as possible, in systems where 1Mb is a lot and all there is I want to squeeze as many of those plugins as possible.
This all means working on no_std support of rust-libp2p to run natively on the microcontroller using whatever is available in the chip like crypto acceleration and different connectivity stacks(LORA, bluetooth, wifi+smoltcp, etc.) and then exposing libp2p to the WASM plugin as an interface so they don't have to bundle it that can be used directly or via a version of libp2p that is just a shell that makes access to the lower level "syscalls" more convenient.

[thomaseizinger]

A different kind of WASM support I'd like to bring to the table and something I'd like to experiment in the coming months(ideas and help will be welcomed) is the definition of a WASI interface that can be proposed later as wasi-p2p or something like that. Is a slightly different kind of WASM integration as the current direction is to be able to compile rust-libp2p to WASM expecting the host to provide calls that abstract the transport like using WebRTC with a set of custom host calls or perhaps the more standardized approach of targeting WASI that will have the sockets abstraction(could/will be polyfilled in the browser).

The proposal I mention is not so much for the browser support or environments that usually run a single bigger WASM blob where libp2p is included, my use case is embedded hardware where I want to allow a very constrained device to run a lightweight WASM interpreter like WASM3 and run many plugins that need to be as lightweight as possible, in systems where 1Mb is a lot and all there is I want to squeeze as many of those plugins as possible. This all means working on no_std support of rust-libp2p to run natively on the microcontroller using whatever is available in the chip like crypto acceleration and different connectivity stacks(LORA, bluetooth, wifi+smoltcp, etc.) and then exposing libp2p to the WASM plugin as an interface so they don't have to bundle it that can be used directly or via a version of libp2p that is just a shell that makes access to the lower level "syscalls" more convenient.

These are some very interesting and exciting ideas! Here are some thoughts on it:

rust-libp2p already implements a kind of plugin architecture. NetworkBehaviours are essentially plugins that can open / close new connections, open substreams etc. I am not sure if going for a wasi-p2p specification will be the most fruitful effort. What I could imagine to work much better is to try and get libp2p-swarm running on the micro controller natively with some static set of transports (bluetooth, tcp, etc) and have each of your plugins expose a component that corresponds to the NetworkBehaviour interface.

Another advantage of this approach is that with the NetworkBehaviour interface boundary, you are already getting a completely declarative interface around all the networking that is taking place. For example, you could easily log / intercept which component is establishing which network connections.

[vincev]

I have implemented a version of the chat example with libp2p WASM clients running in the browser connecting to a Floodsub server using a Websocket transport:

I added the steps to build and run it in the repo. To make deployment easier I have implemented a Websocket transport that uses Websys so that there is no need to package JS bindings and you can build a 100% rust client with a UI library like egui.

Keep in mind that I didn't do any serious testing, this is more of a proof of concept to test libp2p WASM support and get some feedback, I am happy to help and contribute any of this to libp2p if you think it may help.

[mxinden]

Wonderful work @vincev. Thanks for the elaborate README.md.

Keep in mind that I didn't do any serious testing, this is more of a proof of concept to test libp2p WASM support and get some feedback, I am happy to help and contribute any of this to libp2p if you think it may help.

Yes. That would be great! Off the top of my head I am thinking of moving a version of https://github.com/vincev/wasm-p2p-chat into misc/wasm-p2p-chat. What do you think? @thomaseizinger any comments?

[vincev]

Thanks @mxinden I am glad you like it.

Yes. That would be great! Off the top of my head I am thinking of moving a version of https://github.com/vincev/wasm-p2p-chat into misc/wasm-p2p-chat. What do you think? @thomaseizinger any comments?

Sounds good to me, another option would be to have an examples folder for WASM browser apps that would include examples for Websocket and WebCRT but I guess that can be done later.

[thomaseizinger]

Yes. That would be great! Off the top of my head I am thinking of moving a version of https://github.com/vincev/wasm-p2p-chat into misc/wasm-p2p-chat. What do you think? @thomaseizinger any comments?

Could be an opportunity to move towards #3111.

[thomaseizinger]

@mriise Are you still interested in tracking these efforts? With #4015, we now have a web-sys-based transport for WebTransport that is tested using the official interop-tests suite. We also have additional WASM-tests. Plus more and more protocol-crates now compile for WASM, see #3973 for example.

More transports are being added, see #4248 and #4102.

I'd be curious what else we'd be missing. One thing I think would be really great is a full-stack rust-libp2p example where we have a server & a client, possibly reusing a common codebase and deploying them in the browser and as a server.