How about http3?

[adriantabirta]

I was investigating http3/QUIC possibilities. Cannot find any examples of http3 stream api. Maybe in this repo will be ok to add it?

[PeterAdams-A]

What did you have in mind - are you thinking of doing a full implementation in swift?

Note that HTTP/2 has it's own repo.

[Lukasa]

HTTP/3 and QUIC are definitely things we’re interested in. But they’re a non-trivial amount of work. The easiest thing to do in the near future is to bind a third-party library.

[adriantabirta]

As I have found on the internet today everyone have own version of QUIC (different versions implementations and in different languages check), to be able to test in on device I can use Cronet framework, very basic, have no features like streaming. I understand that this is huge amount of work but maybe...

[ConsoleTVs]

Any updates on that? Is this still in consideration?

[Lukasa]

This remains something we want to do, but right now we're simply not able to prioritise the work.

[mzaks]

HTTP/3 RFC 9114 is now officially out https://datatracker.ietf.org/doc/rfc9114/

I would be interested in contributing a pure Swift implementation.

[Lukasa]

If you'd like to tackle that then we recommend starting this as a separate package so you can iterate without requiring our help. Once you've got things up and running we can discuss how we might try to integrate it.

[lmcd]

It's a shame NIO isn't better resourced, as an Apple project 😔 Would love to see QUIC transport implemented - there are maturing implementations now in C, C++, Java, Go, Rust, Node etc. All major browsers and operating systems support it. QUIC has been around for 12 years now and has been a standard for over a year, yet no one has broken ground yet on a Swift implementation.

I'm still not fully familiar with the inner-workings of NIO, and the IETF document is a bit overwhelming for me to parse, but happy to lend time and support in whatever way I can.

[ConsoleTVs]

@lmcd There were different implementations of the protocol here and there. As noted above, the RFC has been published a few days ago.

Swift on server is growing, but it does indeed not have as many resources allocated as I would love to. I honestly think swift is a good replacement in the same space as Go lives. Hope we can get there some day.

[lmcd]

I think there's an important distinction between QUIC, which is the underlying UDP transport, and HTTP/3, which sits on top of QUIC. QUIC became a standard over a year ago now.

I think QUIC is the first hurdle - but once it's in place, it'll open up some very powerful use cases, including, but not limited to HTTP/3.

@ConsoleTVs I agree, I love writing Swift code on the server, but it's going to be hard for companies to justify investment when support for everyday web standards could easily be years away. I don't think HTTP/3 is a 'future technology' anymore. It's becoming the status quo, and I personally wouldn't choose a platform for large new project that didn't at least have a clear roadmap for supporting it.

[kennethlaskoski]

I recently took an interest in Quic and HTTP3 and have been waiting for an implementation in Swift (my favorite language since it appeared). Some days ago I decided to face the challenge and started a project here. It's very incipient and actually does not implement nothing for the moment, as at first I took a top-down approach and created some high-level interfaces that use tcp underneath. I hope that soon I can show something substantial and maybe be considered for integration with SwiftNIO.

EDIT: I forgot to mention that any help would be very appreciated and I'm open for suggestions and criticism. Anyone willing to contribute should not hesitate contacting me.

[lmcd]

I think by far the easiest way of implementing this would be just to borrow some of the work done with Netty and Quic here: https://github.com/netty/netty-incubator-codec-quic

swift-nio is loosely based on Netty and has a similar architecture and concepts of channels, handlers, event loops etc. This implementation also offloads all the Quic protocol stuff to quiche, which is a Quic transport implementation written by Cloudflare and currently used in production: https://github.com/cloudflare/quiche

[kennethlaskoski]

Thank you very much for the suggestions. I'm looking at several projects, including Cloudflare's quiche, but the Netty one have escaped me. I'm surely having a look at it.

[lmcd]

@Lukasa - is there any update on what the thinking is on this internally? QUIC is long standardised now and supported in all browsers, with implementations in all major languages (except Swift). As someone with deeper insights/understanding on all of this, do you think borrowing some of the work done with Netty/QUIC would be a worthwhile or wasted effort?

Is this on the official nio roadmap, or should those of us wanting this migrate away and try our luck elsewhere? Thanks!

[Lukasa]

Hi @lmcd. Unfortunately while we continue to believe that QUIC support is vital, we have no immediate plan to schedule this work.

I think the community could very probably adapt the work done for Netty to bootstrap the work. This is sub-optimal as a long-term solution due to the issues with distributing Quiche in SwiftPM, but it would unblock the use case. In the long-term we’d like to see a full-Swift implementation.

[lmcd]

Appreciate the quick, clear response. Sad that server-side swift isn't yet getting any investment in these modern standards, but fair.

[kennethlaskoski]

I think the community could very probably adapt the work done for Netty to bootstrap the work. This is sub-optimal as a long-term solution due to the issues with distributing Quiche in SwiftPM, but it would unblock the use case. In the long-term we’d like to see a full-Swift implementation.

I've started efforts in these two fronts, a pure Swift implementation and, following @lmcd's suggestion, a façade over Quiche, using Netty as reference. Both works are very incipient and working alone I can't do much to speed things up. My current goal is to achieve a minimum functionality and apply for incubation.

The problem of distributing Quiche is very real. In fact swift-quiche cannot currently be built from a fresh repo clone as there's a missing dependency. I had a repo hosting a Swift Package containing Quiche's binaries but had to delete it to stop Github's complains on bandwidth usage.

[vtolstov]

any good news about this issue?

[Lukasa]

We have nothing to add at this time.

[lmcd]

This repo seems to be undergoing active development: https://github.com/swift-quic/swift-quic

Thanks to @kennethlaskoski and @btoms20 for embarking on this effort 🎉 👏

[kennethlaskoski]

Thanks to Brandon! His work gave a new momentum to our project, it's a first but HUGE step forward in taking an idea to a working implementation.

[btoms20]

The code (that I've contributed) is pretty gnarly in its current form (hackathon type of stuff). But we'd love for people to offer comments / criticism and code if they'd like. Especially at this stage where we're considering the higher level architecture / design of the project.

Also, while we're handing out credit, I'd like to make sure everyone knows that the majority of the networking code is lifted from existing NIO projects, most of which was authored by @Lukasa and the NIO team.

[ranmocy]

@Lukasa Since Apple has implemented QUIC support in the Network.framework like NWConnection, likely back in 2021 (WWDC), I'm wondering if it's possible to extract those works here?

[PeterAdams-A]

QUIC + HTTP/3 remain something the NIO team wants and are getting nearer the top of the priority list.