Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WASM support #2617

Open
3 of 6 tasks
mriise opened this issue Apr 13, 2022 · 10 comments
Open
3 of 6 tasks

WASM support #2617

mriise opened this issue Apr 13, 2022 · 10 comments
Labels
tracking-issue Issues which are the entry point to bigger projects.

Comments

@mriise
Copy link

mriise commented Apr 13, 2022

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


Tasks

Preview Give feedback
  1. send-it
  2. difficulty:moderate help wanted
    thomaseizinger
  3. difficulty:moderate help wanted

Previous Implementations of WASM libp2p

@mriise
Copy link
Author

mriise commented Apr 13, 2022

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
Copy link

olanod commented Sep 6, 2022

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
Copy link
Contributor

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.

@mxinden mxinden changed the title rust-Libp2p WASM Coordination Issue *: Improve WASM support Oct 6, 2022
@vincev
Copy link

vincev commented Nov 6, 2022

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:

clients

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
Copy link
Member

mxinden commented Nov 14, 2022

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
Copy link

vincev commented Nov 14, 2022

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
Copy link
Contributor

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

This comment was marked as outdated.

@DougAnderson444
Copy link
Contributor

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.

💯 Full stack is definitely appealing! I'm looking forward to being able to use protocols like gossipsub isomorphically in the browser and server, not having to trouble shoot or be familiar with 2 different implementations (Rust and Javascript) -- a real bonus.

mergify bot pushed a commit that referenced this issue Sep 17, 2023
This PR implements `Transport` for WebRTC for browsers by using web-sys. Only the `webrtc-direct` spec is implemented. The `webrtc` spec for connecting two browsers with each other is left to a future PR.

Related: libp2p/specs#475.
Related #2617.
Supersedes: #4229.

Pull-Request: #4248.

Co-authored-by: Thomas Eizinger <[email protected]>
@thomaseizinger thomaseizinger changed the title *: Improve WASM support Tracking issue for WASM support Sep 17, 2023
@thomaseizinger
Copy link
Contributor

Changelog:

I've updated the PR description to reflect the current state and deleted several of the old points which I found not to be actionable.

@thomaseizinger thomaseizinger changed the title Tracking issue for WASM support WASM support Sep 19, 2023
@thomaseizinger thomaseizinger added difficulty:hard tracking-issue Issues which are the entry point to bigger projects. and removed help wanted difficulty:hard labels Sep 19, 2023
thomaseizinger added a commit that referenced this issue Sep 21, 2023
This PR implements `Transport` for WebRTC for browsers by using web-sys. Only the `webrtc-direct` spec is implemented. The `webrtc` spec for connecting two browsers with each other is left to a future PR.

Related: libp2p/specs#475.
Related #2617.
Supersedes: #4229.

Pull-Request: #4248.

Co-authored-by: Thomas Eizinger <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tracking-issue Issues which are the entry point to bigger projects.
Projects
None yet
Development

No branches or pull requests

6 participants