nodejs
Create `nodejs/socket` repository for Node.js implementation of Cloudflare's Socket API
👋 I've been working on a Node.js implementation of Cloudflare's Socket API (https://developers.cloudflare.com/workers/runtime-apis/tcp-sockets/). Additionally, I've been working on the spec itself for that API; which is now a WinterCG workstream (https://github.com/wintercg/proposal-sockets-api).
I'd love to not have to own this myself, and would instead be happy to have it live in Node.js plus be published as @nodejs/socket.
What do folks think?
My implementation currently lives here: https://github.com/Ethan-Arrowood/socket and I'll be publishing it to @arrowood.dev/socket soon for early testing.
Is the idea to publish it as nodejs/socket before the proposal is in a spec? Why can’t it just be published as usual on npm for now? I think we need some kind of stage criteria to decide when an implementation is going to be part of the Node.js umbrella or we could end up with multiple unmaintained implementations of inactive proposals (even when the proposals themselves are supposed to be governed by a different organization).
Partially yes; the reality is WinterCG doesn't have the ability to "publish" a spec. We'd love to get there - or maybe have the spec live in another place if that means it could be published. It'll have to remain as a "draft" spec while under WinterCG.
Regardless, we hope that we can get enough runtimes to embrace the API as dictated by the spec that it becomes de-facto standardized.
Totally respect waiting a little while longer - just wanted to get the conversation going here.
as dictated by the spec
I don't remember the TSC have ever discussed about taking compliance of WinterCG specs as mandatory (or, which spec to be taken as mandatory, or when it's the right stage to regard a change as mandatory)...not saying that it should or should not, just saying that I don't recall a serious discussion about this, and from what I can tell it seems like the kind of matter that requires a serious discussion and get the conclusion written down somewhere or even a statement released...
Yes definitely - that is not an assumption by any means. I'm not apart of the TSC so I have no other way to bring the topic up for discussion than in an issue like this. Not expecting anything; love to just get a discussion going that's all
@Ethan-Arrowood you're always an appreciated/valued member of this project - I think the question is, what's the context? Why would we want to ship the Cloudflare workers socket API under the Node project umbrella? What's the motivation?
Thank you @benjamingr ❤️
Those are great questions; my apologies for not making this issue more clear.
what's the context?
The context for this issue started from a conversation in the WinterCG Matrix channel:
This chat is public and available for anyone to join and read: https://app.element.io/#/room/#wintercg:matrix.org
Previously, I opened: https://github.com/nodejs/node/issues/49231 but it received no response.
Why would we want to ship the Cloudflare workers socket API under the Node project umbrella? What's the motivation?
I'd love to focus on answering/discussing these questions. IMO the Socket API is a great UX/DX improvement for TCP networking. I see it very similar as fetch is for HTTP networking. The Socket api and specification are currently evolving in the open within the WinterCG so that all runtimes can have an opportunity to influence its development. While yes it started as a Cloudflare api and is being mainly driven by them (and myself), it has reached a point where we would extremely appreciate more input from the community.
I personally think Node.js could benefit from an improved TCP/TLS api. I also think the Socket api could be that improvement. What do other people think?
If this is bound to become the socket API for (server-side) JavaScript runtimes, that makes sense to me. If that's not certain, then I'd appreciate if we didn't reserve nodejs/socket just yet.
Feeling of smallish number of people we had in the TSC meeting today (6) was that its premature to pull into the nodejs repo at this point.
At the TSC meeting today we discussed it a bit and some of us think that it may make more sense to put it under the WinterCG organization, as as a standard this is still WIP, and this is more like a polyfill at this point. Historically when polyfills are implemented for WIP standards they are maintained alongside with the standards.
My 2 cents: it would be nice if WinterCG has some kind of staging process like TC39 does. What we lack here is that we don't know how mature the API is yet (especially how mature it is to be "the" socket API as @tniessen pointed out). Having some staging process based on the maturity of the API would help us decide when some API and its polyfill should continue iteration in the standards venue, when some API is mature enough to be published as an official polyfill, and when some API is mature enough to be moved into core.
WinterCG rejected hosting the code for this as they do not have the governance in place to manage it responsibly. As WinterCG seeks more official standing, that may change.
We discussed in the TSC meeting today and agreed to remove from the agenda. The consensus seems to be that it's to early to take that namespace/pull in to Node.js org. If there were more signals from WinterCG that might help. Please re-add to tsc-agenda if you feel we should discuss further.