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.
It's backwards! Unlike webrtc, iroh doesn't work inside a browser. It's for the case where you have two native apps that need to talk to each other p2p.
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!
Yes! that's the "other reconstruct" I mention on the post. maxMessageSize at least appears in SDP and getStats. We ended up patching both at our client to be safe [800 bytes and 16kb respectively].
Would agree it's uncommon in general traffic. Rare conditions [webrtc-rs, 1280 class tunnel / tailscale, and ipv6 pair] but deadly when they are met since every connection silently fails. That's what made it worth chasing down for 2 weeks [and good for sleuthing :)].
Author here, thank you, that means a lot coming from you. Pion was the prior art I pointed the webrtc-rs maintainers at. And pion/sctp#12 is super relevant. A known, proposed fix years before we hit it.
"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.
At the very least this sort of thing [building] can be cathartic. I hope it helped you in your situation and that the process itself made it worth it, even if it doesn't become a thing. I hope it does!
Had AI help me write a blog post last week. Most of the process was deleting verbosity. I guess it solves the blank page problem but once you get going the noise is worse than doing it yourself.
Reminds me of my dad's experience with google nest hub a few months ago. He called it the best product google's ever made until an over the air update killed the video call feature he used to talk to his grand kids. Brutal.
I've gone back and forth too. Your point about the missed learning/re-enforcement opportunity is real, and the temptation to gloss over things is too.
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.