Apologies I should have been more precise. What I meant was it doesn't work on the browser support in the way webrtc works on the browser. The point of webrtc on the browser is to establish a peer to peer connection.
61 karma · joined April 12, 2016
For browser / webapps you want webrtc.
This would give you a native iroh node that also speaks webrtc but I find that what folks want is for browsers to participate as peers.
I build p2claw, p2p for self-hosted web apps, and ended up doing both halves separately. Box to box is iroh, although I use my own coordinator service and run my own iroh relay. Browser to box is webrtc with a service worker that makes the browser act like a peer. The worker grabs fetches and sends them as HTTP frames over the data channel, the box answers on localhost. The browser bit has to be webrtc because it's the only browser api does ICE.
Wiring up the iroh half went smoothly, very much enjoying working with the library. Congrats on 1.0!
Though maybe I’ll keep my old limits for old browser compatibility.
"The hardcoding we all settle for" might be the epigraph for the whole incident. webrtc-rs invited a PR for the configurable-MTU + better default half [webrtc-rs/webrtc#806] to unblock folks today. Whether PMTUD gets implemented will be interesting to see.
Agreed. The port-number point is the most plausible rationale I've heard, more convincing than the RFC line in their source comment. The historical fix for "can't classify fragments" was virtual reassembly or flow tracking [conntrack on linux, scrub in pf], so dropping them outright punts past known prior approaches. Even your lighter idea would have saved us: a first-fragment match would have let our pair through.
We've reported upstream to both projects, tailscale/tailscale#20083 and webrtc-rs/webrtc#806, and webrtc-rs already invited a PR.
This started as a blank page on one device and ended two weeks later at the intersection of two bugs: webrtc-rs hardcodes INITIAL_MTU=1228 [never updated, no path probing, retransmits at the same size forever], and Tailscale's packet filter classifies any IPv6 packet with a Fragment header as unknown protocol, so the default deny fires. On every platform, counted under reason="acl". Neither is unreasonable alone. Together: silent wedge, every health check green, because everything that tests the path is small and only the payload fragments. Two-command repro on any tailnet: ping -s 100 works, ping -s 1400 over the Tailscale IPv6 address is 100% loss. Full WebRTC repro and captures: https://github.com/phact/mtu-webrtc-bug. We've reported upstream to both projects https://github.com/tailscale/tailscale/issues/20083 and https://github.com/webrtc-rs/webrtc/issues/806. Happy to answer questions. Especially interested if anyone knows the history behind the IPv6 fragment decision in Tailscale's filter.
Did you just tell me to go fuck myself ?
That said, I'm starting to think differently about what I consider worth learning deeply. Given that syntax is fully automatable, it is now less of a priority for me. I'm focusing more on architecture, protocols, and product and on trying to build software that actually helps me and folks in my life, especially out side of work.
For example I had 3/4 toy projects last month [mostly vibecoded], a gag birthday website for my brother, a presentation framework I used for my kid's spanish class, etc.
I ended up getting curious about whether there was a way to sidestep traditional dns / cert deployment mechanisms and host vibe coded apps more simply. Ended up building p2claw dot com. Surprisingly webrtc is a good way to serve peer to peer web apps. I've been using it a bunch and it works well. I won a demo day presentation with it and the creator of webrtc replied to one of my tweets :)
I guess tl;dr, AI code let's you think about bigger things and try more unexpected projects.