Iroh on the web

[anderspitman]

Iroh looks like a very interesting project, and one that could power some really important software in the future.

I've read https://www.iroh.computer/blog/iroh-and-the-web. There's also some discussion in #1803. Happy to go back there if it's a better place to continue the conversation.

Basically I'm wondering if the project might reconsider its stance on WebTransport and/or WebRTC.

In the article above, the stated reason for not using WebTransport is that it's client-only in the browser. This is a valid concern. However, in a world where you're always going to need STUN/ICE or equivalent anyway to punch through NATs and firewalls, does it really matter that much who's technically doing the listening? I haven't done much p2p work so it's possible that it does matter, but I'd appreciate more clarity on this. Apparently it's also possible for clients to validate certs without involving a CA0, which is cool.

The article says the reasons for not pursuing WebRTC is that the runtimes are heavy. I just tried compiling an example from webrtc-rs. While simple, it was capable of communicating with my browser. The release executable came in at 13MB. Compiling the iroh-net listen example resulted in a 334MB executable. That's big enough to make me think I must be doing something wrong. In any case, iroh-net does have about 70 dependencies so I suspect it's not going to be smaller than 13MB.

The article also says this:

We'll see what we can do once we get here. Perhaps by then WebTransport will be extended to support direct connections?

I honestly don't think this is ever going to happen. As far as I know there's no working happening around this. I think you probably either need to commit to relays forever, or use WebRTC or WebTransport.

That said, you're probably always going to need relays for some percentage of connections. Tailscale has a nice breakdown of the numbers1. I suspect the best approach today is something similar to Tailscale, where you bootstrap via DERP (which you're already doing) and opportunistically upgrade to QUIC, but in your case it would be WebTransport or WebRTC.

I'm probably making too many assumptions here, and would love to learn more about the various tradeoffs for the project.

[matheus23]

Hi, happy to see so much excitement for iroh :)

in a world where you're always going to need STUN/ICE or equivalent anyway to punch through NATs and firewalls, does it really matter that much who's technically doing the listening? I haven't done much p2p work so it's possible that it does matter, but I'd appreciate more clarity on this. Apparently it's also possible for clients to validate certs without involving a CA0, which is cool.

Doing the listening in the sense of "listening for incoming connections"?
The best we can do with WebTransport (with the serverCertificateHashes option you mention) is browser nodes never being able to listen for connections and only being able to dial other non-browser nodes, at least directly. Otherwise the relay fallback will always be there. I do think browser nodes not being able to connect directly is quite restrictive.

Basically I'm wondering if the project might reconsider its stance on WebTransport and/or WebRTC.
[...]
The article says the reasons for not pursuing WebRTC

Hm. Perhaps there's a misunderstanding. We're aware of WebTransport and WebRTC and we do want to explore those options, that's why they're mentioned in "Phase 3".
It's just that for the first iteration we're focusing on relays.
And it's also that we're not married to a single solution yet, as unfortunately both come with drawbacks.

We'll see what we can do once we get here. Perhaps by then WebTransport will be extended to support direct connections?

I honestly don't think this is ever going to happen. As far as I know there's no working happening around this. I think you probably either need to commit to relays forever, or use WebRTC or WebTransport.

Well, maybe. There's work on direct WebTransport connections in the local network being specified at least: https://github.com/WICG/local-peer-to-peer/blob/main/EXPLAINER.md (See the LP2PQuicTransport especially).
Apparently, originally, the design for WebTransport included p2p, but it was scrapped.

I just tried compiling an example from webrtc-rs. While simple, it was capable of communicating with my browser. The release executable came in at 13MB. Compiling the iroh-net listen example resulted in a 334MB executable. That's big enough to make me think I must be doing something wrong. In any case, iroh-net does have about 70 dependencies so I suspect it's not going to be smaller than 13MB.

This depends on how you configure compliation. By default cargo build --release will omit debug info. We specifically turn that on for iroh in our repository (See the root Cargo.toml), so that's why the executable is quite a lot bigger. When I turn off debug info, I get a 46MB executable for the iroh CLI, and an iroh-net example clocks in at 22MB.

[matheus23]

Closing in favor of a unified issue: #2799