msquic

What will the socket API look like for multiple streams? I guess it is implied it is the same as multiple connections, with caching behind the scenes. I would hope for something more explicit, where you get a connection object and then open streams from it, but I guess that is fine for now. https://github.com/microsoft/msquic/discussions/4257 ah but look at this --- unless this is an extension, the server side can also create new streams, once a connection is established. The client creating new "connections" (actually streams) cannot abstract over this. Something fundamentally new is needed. My guess is recvmsg to get a new file descriptor for new stream.

> At the same time, neither QUIC nor HTTP/3 are included in the standard libraries of any major languages including Node.js, Go, Rust, Python or Ruby. .NET actually looking like it has decent support for any teams that are interested[0] (side note: sad that .NET and C# are not considered "major"...). There is an open source C library that they've published that seems rather far along[1] Support for Windows, Linux[2], and Mac[3] (the latter two with some caveats). Overall, I think for most dev teams that are not building networking focused products/platforms, HTTP/3 is probably way down the stack of optimizations and things that they want to think about, especially if the libraries available have edge cases and are too early for production. Who wants to debug issues with low-level protocol implementations when there are features to shi