Repository navigation
Looking for someone to take over the quic impl #61741
Description
Activity
Hey, I'd like to help with this.
Reacted by James M SnellI'd be happy to help 👀
Reacted by James M SnellI'm happy to help as well
Reacted by James M SnellHey, if a team is created, I’d love to join to help :)
Reacted by James M SnellI'm interested 👍
Reacted by James M SnellOk, I'll get a call set up for next week (I'll post a doodle poll in the next day or two to collect availability). Between now and then I'll create a summary document that outlines where things are at and what is remaining left to do.
Reacted by Mert Can Altin and Tim PerrySign me up; I looked at trying to help with tests in the past but couldn't totally figure it out.
More concentrated direction is key and will be very helpful here.
Reacted by James M SnellReacted by James M Snelldavidarmandosanchezcruz54-source commented
on Feb 10, 2026 on Feb 10, 2026 · Hidden as off-topicshow commentMore actionsdavidarmandosanchezcruz54-source commented
on Feb 10, 2026 on Feb 10, 2026 · Hidden as spamshow commentMore actionsBlocked the spammer and deleted the (several+) comments. (Just for visibility and documentation of the action)
Reacted by James M Snell, Mert Can Altin and TyIsIDefinitely interested in helping 🙂
Reacted by Mert Can AltinI can help, but I am not so familiar with node.js intrinsics. What I can offer is experience with Webtransport over quic (and a suite of tests, probably good to be ported over to node.js) and also experience in finding race conditions in quic streams etc. (a few patches with major browsers) and I am primarily a C++ dev.
P.S: I would be glad if someone could review my PR #60237. Even though it says it is an added feature, it turned out to be mostly a collection of fixes for different race conditions; it will probably help as a basis. That is also the reason for the ugly number of commits, and, of course, I need some guidance to make it more in line with the current Node.js code, but I need review and advice.
Sorry, got delayed in setting up the call. here's the doodle poll for possible meeting times this next week: https://doodle.com/group-poll/participate/bon624La
The doodle poll suggests we're meeting today (8pm UTC). Is that happening? I'm available.
I am also wondering, otherwise, I would do something differently this evening.
Sorry all, this week ended up turning into a bit of a nightmare scheduling wise. I'm going to reset the doodle poll with some times for next week and going from there. Sorry for that :-/
Reacted by Ethan Arrowood, mannie.exe, Ramsundhar Madhavan, EVA (Entity Value Attribute) and Carlos FuentesReacted by TyIsIIf it's challenging to schedule this as a standalone thing, might it be easier to get together as part of the summit in a couple of weeks?
Ok, the past few weeks haven't gotten any easier in terms of my schedule... I have, however, had some time to shore up some of the c++ side to fix some long standing issues (there's an open PR). I think resetting and planning for a discussion during the collab summit ... even if an informal one... is a good idea.
Reacted by Carlos Fuentes and Tim PerryReacted by TyIsIOk. so I managed to dedicate some time to completing a large bulk of the quic work over the past month and landed a major update this week. There are over 200+ tests, the http3 implementation is functional, streaming payload support is added, etc. At this point, the implementation is at a point where it's functional but not yet complete. What's left? Validation, Bug Fixing, and Refining.
What we need:
We need people trying to use it and reporting back what doesn't work.
For now, this will require manually building as it is not built in Node.js by default.
./configure --experimental-quic make -J{nproc}While there are a number of API improvements still to be made, the biggest effort right now needs to be on identifyings the bugs and gaps in the implementation.
Where to start? Build things. Try things. Experiment. Document was is odd. What doesn't work. What bugs show up. Don't just accept oddities that show up, flag them. Some things might appear to work but actually don't. For instance, if a test completes but takes 10 seconds to run, it's probably a bug because the connection is hanging and hitting the 10 second default idle timeout in a connection where instead it should be closing down immediately. No errors might be reported but the behavior is wrong, etc.
@nodejs/build team... it would be helpful if we could get some configurations in ci.nodejs.org that will build and run the custom configuration for us... not as part of the regular CI jobs since I would expect the build to fail on at least some of our supported platforms, but as a dedicated manual path. We'll need it to verify that we can actually build this on all supported platforms.
@nodejs/build team... it would be helpful if we could get some configurations in ci.nodejs.org that will build and run the custom configuration for us... not as part of the regular CI jobs since I would expect the build to fail on at least some of our supported platforms, but as a dedicated manual path. We'll need it to verify that we can actually build this on all supported platforms.
If we wanted it on all platforms perhaps a periodic trigger of node-test-commit against it might be the simplest option.
Otherwise I guess we could have a separate multiconfig job similar to the stress test one that pulled from the branch and had a set of suitable configurations. Do you know which platforms it's likely to fail on?
... Do you know which platforms it's likely to fail on?
I have no idea yet. Planning to do a CI test run likely early next week to see.
Reacted by Stewart X Addison- addedquicIssues and PRs related to the QUIC transport implementation.Issues and PRs related to the QUIC transport implementation.
on May 11, 2026 Thankfully, things changed, and James found time to contribute to QUIC after all 🙂
https://github.com/nodejs/node/pulls?q=sort%3Aupdated-desc+is%3Apr+author%3Ajasnell+label%3Aquic+is%3AclosedAnd we have nine members in @nodejs/quic who are also actively working on it.
Should this issue be closed?
I think it's time I faced reality: I'm not going to find time to finish the QUIC implelementation myself. I've tried, but there's just way too much on my plate to be able to get back to it. I'm looking for an existing core contributor willing to take it over.
Why an existing core contributor
The implementation is mostly in C++ and requires a fairly deep understanding of how the C++ internals in Node.js work. Most of the implementation is done but any bug fixes, performance improvements will be done there and it's going to need someone with a fair amount of c++ experience to work on it. The JS layer does need to be worked on but that's a fairly thin layer on top of the underlying implementation.
A new contributor might be able to pick it up but there's a ton of context and understanding of the internals that will need to be understood.
To be clear, it doesn't need to be just one other person. I think ideally we'd have a team working on it.
What is left?
The basic impl is there, the basic architecture is there. What is remaining are the tedious details needed to get it over the line. Mostly it's in how the QuicStream works (
src/quic/stream.{h/cc}). The Endpoint and Session stuff is largely in place but probably needs fine tuning.I'm happy to guide
I'm happy to mentor/guide whomever takes it over I just cannot justify the time necessary to do the development myself and I'd really like to see it finished this year if possible.
I'll keep this issue open for a week or two then set up a call with the volunteers to start a transition.
Prerequisites
src/quic