Great interaction. Very refreshing after some of the past problems I've encountered with maintainers treating forks as hostile or "stealing our work".

The message also exposes a reality of how hard it can be to upstream internal changes: They admit they don't have the time to go back and re-submit all of their work as tiny incremental patches that could be reviewed and approved upstream. They estimate it would be on the order of 100 PRs necessary to break it up and get it reviewed. That's a very large time investment for a company that needs to keep moving forward.

Hopefully they stay close in the rest of the implementation details of the project they forked from. After a fork becomes battle-tested enough it might be reasonable to start merging things in larger chunks rather than treating them as incremental development again.

I very much agree, a nice contrast to so much open source drama

The zero-config part is where it gets tricky in practice. I spent a while getting mDNS-based discovery working across different home networks and it's a mess. Half the consumer routers silently drop multicast between subnets, some just rate-limit it into uselessness. You end up layering fallback after fallback (broadcast, then direct probe, then relay) and writing heuristics to pick which path actually works. Having multipath baked into QUIC so the transport just tries all paths and converges on the best one would've saved me a lot of that.

You may be interested in my list here: https://github.com/anderspitman/awesome-tunneling

In particular I believe OpenZiti has a similar focus on embedding the tunnel in the apps.

Good to know. I usually use magic wormhole, which works great, but it does install a lot of python modules to achieve it. I'm always a little reluctant to install that on our production Windows SQL servers, and I rarely touch them, so usually when I do I just do a "netcat" equivalent via either a powershell snippet or https://github.com/linsomniac/toothpyk or I just "wget" it on the Windows side. For SQL Server ISOs, the Windows built in wget is terribly slow though.

Thanks for the sendme pointer.

It turns out that "Have the defaults arranged so that they suit a handful of crazy people but inconvenience literally everybody else" isn't popular. In fact preferring a tiny minority preference is sort of inherently unpopular, that's basically its defining feature as a policy.

Now, see. that's what I said as well. But the rest of the team was tired of me trying to name the hosted iroh "n0des", which I'm now ready to admit was a stretch. And so now here we are spelling n0q as noq. c'est la vie.

Many QUIC features get implemented while in draft stage as people iterate on the RFC's design (e.g., ACK Frequency[0] is currently on draft version 14 and I implemented support for it three years ago in quinn).

[0]: https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-fr...

It’s common enough for groups to not consider the spec done until there is a decent bit of implementation experience (both because actual implementers tend to find interesting bugs in specs, and because many things are hard to measure without any implementation).

It's been a draft for a long while, and was only recently approved

It’s pretty common for IETF drafts to be substantially complete well before they are finalized as RFCs. For example, supporting ML-KEM in TLS is still a draft, but there are already multiple large scale deployments of it since the technical aspects were nailed down a while ago