You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 26, 2022. It is now read-only.
We are using libp2p in 0xProject/0x-mesh. Our goal is to have a single codebase written in Go which can be run as a standalone server or compiled to WebAssembly to run in the browser. We have already made a lot of progress toward that goal by adding WebAssembly support to some of our dependencies: pion/webrtc, goleveldb, and parts of go-ethereum. A large portion of our codebase already works in WebAssembly and we even run WebAssembly tests in CI on a regular basis. One major component that is still missing is a WebAssembly-compatible transport that can run in the browser.
I opened a spec proposal for allowing two browser-based peers to connect directly to one another via WebRTC. While some details of the spec still need to be worked out, it's become clear that some sort of intermediary server will be required. I believe WebSockets are the ideal transport for communicating with an intermediary server as part of setting up a direct browser-to-browser connection. In order to enable that I'd like to add WebAssembly support to the existing WebSocket transport. The WebSocket transport can also be used to establish relay connections as a fallback in the event that a browser-to-browser connection cannot be established.
There is already an open issue to add WebAssembly support to gorilla/websocket. If we can make that happen, there should only be minimal changes required in this repository. It would involve updating the dependency and adding some tests specifically for WebAssembly so we can make sure nothing breaks.
Is this something you'd be open to and would you accept a PR?
The text was updated successfully, but these errors were encountered:
You should take a look at ipfs/kubo#5694 and all the related PRs.
Is this something you'd be open to and would you accept a PR?
As log as it doesn't increase the code/dependency size on non-wasm builds too much, absolutely! I assume the deps would only be pulled in when building for a wasm target.
If you can't get this into gorilla/websocket, consider making an entirely new transport. go-libp2p would then have to be modified to use that transport by default, instead of go-tcp-transport + go-ws-transport, when compiled on a wasm target.
We are using libp2p in 0xProject/0x-mesh. Our goal is to have a single codebase written in Go which can be run as a standalone server or compiled to WebAssembly to run in the browser. We have already made a lot of progress toward that goal by adding WebAssembly support to some of our dependencies: pion/webrtc, goleveldb, and parts of go-ethereum. A large portion of our codebase already works in WebAssembly and we even run WebAssembly tests in CI on a regular basis. One major component that is still missing is a WebAssembly-compatible transport that can run in the browser.
I opened a spec proposal for allowing two browser-based peers to connect directly to one another via WebRTC. While some details of the spec still need to be worked out, it's become clear that some sort of intermediary server will be required. I believe WebSockets are the ideal transport for communicating with an intermediary server as part of setting up a direct browser-to-browser connection. In order to enable that I'd like to add WebAssembly support to the existing WebSocket transport. The WebSocket transport can also be used to establish relay connections as a fallback in the event that a browser-to-browser connection cannot be established.
There is already an open issue to add WebAssembly support to gorilla/websocket. If we can make that happen, there should only be minimal changes required in this repository. It would involve updating the dependency and adding some tests specifically for WebAssembly so we can make sure nothing breaks.
Is this something you'd be open to and would you accept a PR?
The text was updated successfully, but these errors were encountered: