syllogistic

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.

For browser / webapps you want webrtc.

> when will iroh support 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!

Good to know, thanks!

Though maybe I’ll keep my old limits for old browser compatibility.

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.

Author here,

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.

How do these results compare with the engram based approach from deepseek?

Is he headline strictly about subsidized subscriptions? Anthropic announced their first profitable quarter.