Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create nodejs/socket repository for Node.js implementation of Cloudflare's Socket API #826

Open
Ethan-Arrowood opened this issue Sep 8, 2023 · 12 comments

Comments

@Ethan-Arrowood
Copy link

Ethan-Arrowood commented Sep 8, 2023

👋 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.

@joyeecheung
Copy link
Member

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).

@Ethan-Arrowood
Copy link
Author

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.

@joyeecheung
Copy link
Member

joyeecheung commented Sep 10, 2023

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...

@Ethan-Arrowood
Copy link
Author

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

@benjamingr
Copy link
Member

@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?

@Ethan-Arrowood
Copy link
Author

Ethan-Arrowood commented Sep 11, 2023

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:

Screenshot 2023-09-11 at 11 16 15

This chat is public and available for anyone to join and read: https://app.element.io/#/room/#wintercg:matrix.org

Previously, I opened: nodejs/node#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?

@tniessen
Copy link
Member

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.

@mhdawson
Copy link
Member

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.

@joyeecheung
Copy link
Member

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.

@joyeecheung
Copy link
Member

joyeecheung commented Nov 29, 2023

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.

@Ethan-Arrowood
Copy link
Author

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.

@mhdawson
Copy link
Member

mhdawson commented Dec 6, 2023

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.

@aduh95 aduh95 removed the tsc-agenda label Dec 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants