Hi, Speaking with only the hat of a QUIC implementation maintainer and addressing some of the API topic.
On Wed, Jan 7, 2026, at 13:48, Chris Box wrote: > Reviving this thread for the new year. > > On Sat, 22 Nov 2025 at 17:24, Michael Welzl <[email protected]> wrote: >> Hi, >> >> These minutes are great, thanks! Seems like it was an interesting >> conversation. > > Agreed. My takeaway is that evangelising the benefits of H3 over H2, > supported by some new public data, would really help. Data on the problem > areas, with advice on how to handle them is also needed. This can then spur > development of libraries and encourage shipping with default-on configuration. >>>> Need better tools in programming languages to make it easier to use QUIC. >> FWIW, this is why the TAPS WG existed, see RFCs 9621, 9622, 9623. It would >> be great if we could get some momentum towards more implementations, >> specifically ones that use QUIC… surely there’s no easier way for people >> to access QUIC’s features without having to care about the specifics. > > I agree the modern Transport Services API should be encouraged. > https://www.rfc-editor.org/rfc/rfc9623.html#name-existing-implementations > lists Apple's Network.framework, NEAT and two Python implementations. > >> I currently have two master students working on implementations that will >> use QUIC, but that’s as much as *I* can offer, from the world of academia. > > Thank you for that! > >> PS: there’s also https://github.com/tfpauly/draft-taps-quic-mapping but it’s >> going stale… > > It strikes me as odd that 9621-9623 didn't include support for 9000. Is there > a reason why the QUIC mapping wasn't seen as important? >From my experience, API development and maintenance are a huge cost center. >While an API definition might do some of the work, theres an iceberg beneath >that. The quiche project I maintain provides a low-level Rust library for QUIC, with a FFI to allow usage from C. Similarly there is a low-level HTTP/3 layer that sits on top with Rust and FFI APIs. The expectation is that these are integrated in an application that provides the I/O and event runtime. Its is common that HTTP applications have their own programming/object model and API (potentially 1st parh1ty or 3rd party common libraries). quiche is used to power several Internet-scale production systems at Cloudflare. Its used by other folks at scale too, who can name themselves. It can also be used as a backend for curl. The project is active and embraces QUIC's innovation capabilities. We regularly tweak the API as we learn from deployment experience, introduce new IETF work, or run other experiments or trials. quiche is not the only Rust implementation. neqo, quinn, and s2n-quic are some more-widely known ones, and there are others. One of the common anecdotes I've heard over past years is something like "I really wanted to use quiche but my project is using async Rust which is not directly supported. I didn't want to have to write ans maintain my own layer, so I used quinn instead". I'm not going to begrudge people picking software that lets them get on with life. The lack of a quiche async friendly API was primarily down to the project maintainers not needing one. In recent years, that's changed and in the last year we've open sourced "tokio-quiche" [1], which sits further atop the low-level libs mentioned above. As much as it might pain people to hear, I struggle to see what benefit a TAPS-like interface would provide. It sounds like a tonne of work that would introduce friction to my ongoing project needs. I have no idea what it would mean for the applications that build on top it. I doubt we'd use it ourselves and it would likely become a second class citizen. More recently, I've seen people brand new to the world of QUIC use AI-coding assistants to quickly build functional prototypes using quiche or tokio-quiche. I suspect they could switch implementation easily too, if required. If one of the arguments for TAPS is that it reduces the barrier for new entrants to try the QUIC protocol, I think that argument is being rapidly eroded. Finally, another statement that others might find controversial. IMHO if you have a custom application that can just be flipped from TCP to use QUIC by a couple of lines or flags, I suspect that the application is so simple that there's going to be very few benefits to QUIC. The new dimensions of operational considerations will likely kill any enthusiasm gained from a simple flip-on switch. For more-complicated applications, then its likely they've already invested in a stack of technologies and build the abstraction they already need. Cheers Lucas [1] https://blog.cloudflare.com/async-quic-and-http-3-made-easy-tokio-quiche-is-now-open-source/ > > Chris
