[RFC] WASM

[Jorropo]

I would like to run code in the browser however I hate JS and JS hates me.

It would be nice if go-libp2p would magically work in the browser (with gopherjs and or GOOS=js GOARCH=wasm).

IO would be provided in a degrated mode supporting websocket. (https://pkg.go.dev/nhooyr.io/websocket#hdr-Wasm)
We could also do webtransport and webrtc but we would need to write the syscall/js wrapping code ourselves which might be more or less complex.

One potential issue which makes this less straight forward than it may seems, is that even if the big required elements like WS are reachable, the options that can be applied are way less diverse making some low level config impossible.

---

Current status of this PR:

• Todo:
  • Websocket implementation brought back from the dead.
    • I don't like it, the code isn't good because the websocket API really sucks (no backpressure, callback based).
      It's probably worth removing it and relying exclusively on webtransport as long as https://developer.chrome.com/articles/websocketstream/ is not a thing. (we could also use a JS polyfill mapping websocket to the streaming API that webtransport is also using).
  • New Webtransport syscall/js implementation
    • Tests
  • WebRTC
    • I don't want to start writing the shim before add WebRTC transport #1999 is merged.
• Examples:
  • Chat example !
  • Kad DHT
    • It compiles and runs on my machine but very quickly crashes chrome but the DHT doesn't work properly due to the lack of publicly announced webtransport addresses in the wild + a limit of 6 concurrent webtransport connections imposed by the browser.
• Browser support:
  • 🟡 Chromium (SIGSEV a lot for whatever reason)
  • 🔴 Firefox, lacks support for serverCertificateHashes https://bugzilla.mozilla.org/show_bug.cgi?id=1806693
  • 🔴 Safari, no webtransport

[p-shahi]

Supporting Wasm hasn't come up in any discussions thusfar, but why go-libp2p vs the Wasm support that rust-libp2p provides?

[Jorropo]

Because I'm bad at rust (/ want to use it with the rest of my go code, like go-libipfs).

[Jorropo]

The FX issue is fixed in master just unreleased: uber-go/fx@5e90c38

[Wondertan]

Celestia would support these efforts. We have a notion of Light Nodes that can access the chain state in trust minimized manner, and we want to experiment with running them in the browser over WebTransport/RTC. We don't have a rust implementation of the protocol and do not plan to have it soon, so Golang would be appreciated, even considering how inefficient it is.

[MarcoPolo]

@Jorropo how much of go-libipfs compiles to wasm? What about kad and pubsub?

I have some thoughts I've been drafting about a need to be able to compile protocols into a wasm module. Then have plumbing to allow every implementation to use the same wasm protocol module. I'll link them here when they're ready.

As for this, it's definitely cool but I'm expecting not practical besides for demos. If you do get it to compile, my guess is that the bundled size will be pretty big (I hope I'm wrong!). So I don't expect core go-libp2p maintainers to spend effort maintaining this anytime soon.

[Jorropo]

how much of go-libipfs compiles to wasm? What about kad and pubsub?

I would guess they work out of the box, given they don't call any io themselves.

In general, anything compiles to wasm, the language is fully implemented, however the API you have access to are pretty limited.
In theory if we fix direct io based stuff (transports, local interfaces discovery, ...) then any libp2p would work out of the box.

the bundled size will be pretty big

You are probably right, however I don't think the bundle size maters much for let's say a browser application that implements a gateway, you download it once and then keep it cached.

[MarcoPolo]

Closing the PR as part of some spring cleaning. Still excited for this though :)