Decentralized module delivery

[scriptjs]

I am asking that the TSC begin to explore a future of module delivery for node that is decentralized. Along with this, it should assume control of determining future standards around the use of the package.json. A decentralized approach (as opposed to what today is centralized) for module distribution is safest at scale. The Web itself was designed around this philosophy and it is a useful model for the scale of node.

Further, the node community and TSC must retain control over the user experience of node. The future of module delivery can and should involve multiple players that deliver according to standards that are developer driven and in consultation with the TSC that can assure this interest.

The process of moving forward can and should involve the community in determining possible approaches, tests, and be given careful consideration over time since we are now into an LTS approach to releases. This future can evolve with es6 and with the purpose of moving away from the legacy of a single upstream service.

[Fishrock123]

@scriptjs could you move this issue to https://github.com/nodejs/NG? It'l probably be better over there.

[scriptjs]

@Fishrock123 I created nodejs/NG#26 for this but would like this issue to remain since I don't see this as a very long range goal. I rather see this as a priority since alternate approaches can begin to be discussed, considered and tests undertaken well in advance of the fully restructured node of our future.

[ChALkeR]

I guess I should leave this here: https://twitter.com/izs/status/690385503519117312

[bnoordhuis]

Huh, so npm, inc. is acting as moral guardian too, now? What could possibly go wrong?

[defnorep]

@bnoordhuis: I didn't even see any white smoke.

[joshmanders]

While I understand izs made a joke (since deleted it), it still worries me that we put so much reliance on a company who can, and will make such claims.

[joshmanders]

For those wondering, Izs made a joke saying anyone who breaks npm code of conduct on github gets blacklisted from the registry by ip (as if github gives ip addresses of users to a 3rd party like npm anyway)

[ChALkeR]

@joshmanders That didn't look like a joke to me.

See the following threads: one (asking him if he is serious), two (regarding the IP source), three.

[joshmanders]

@ChALkeR wow I didn't see those. I retract my statement and my worrying intensifies.

[jasnell]

While we do need to make sure that any issues are surfaced, we need to make sure we don't jump to conclusions or have a pile on with this. Let's make sure we keep the conversation productive and let's keep in mind that this issue tracker here is to track technical issues with Node core. A more appropriate location for this discussion would likely be the issue tracker in the nodejs/TSC repository (https://github.com/nodejs/TSC).

[isaacs]

Participation in npm has been governed by a code of conduct since its creation. Originally, when "npm" was just me, that code was understood and enforced by me alone.

When I transferred ownership and maintenance of the registry to a corporate entity, I enlisted the help of several professionals to help document exactly what that code of conduct is, and how we ought to enforce it. It's been documented very clearly on our website since May of 2014.

The OP asserts that module delivery and creation is a core value proposition of the node user experience. This is 100% correct! That value was not created by the TSC or the core team. It was created by npm and by the users who have participated in this community, following the norms of conduct documented in the npm CoC.

If the TSC wants to undertake the task of building a distributed registry system, you have my blessing. It would be a neat project. It would probably make sense to make the public registry a seed/root node in this distribution network. (We're already talking to some folks involved with ipfs to do exactly that.) But it would be wise to consider why the current (centralized) npm registry has been so successful, if widespread usage is the goal. It's not cheap or easy, and would represent a significant shift in the NF budget (and most likely the funding requirements of the foundation) if it's going to take on anything like the public registry traffic.

I am shocked and confused by the FUD around this. npm is morally required to enforce our code of conduct. We always have, and it should be no surprise. It's not difficult to avoid harassing people. Node.js already has its own CoC, and npm and Node.js have worked well together for many years.

I've deleted my tweets talking about our CoC. It's too nuanced for twitter, and frankly I don't need a bunch of people explaining the limits of IP-based blocking to me as if I said that's the only moderation tool available.

[isaacs]

@ChALkeR @jasnell I agree. Discussing decentralized module delivery is a great idea. Doing so because of some FUD around npm "going rogue" and enforcing a CoC that's been in place for almost 2 years? That's the wrong approach.

Close this issue if it can't stay on-topic, though. Or ruthlessly delete/edit any responses that are not on-topic (including mine above, and this one). Or close it if the discussion belongs elsewhere. My $0.02.

[ChALkeR]

@isaacs Sorry, I moved my post elsewhere. Now that you have answered it, restoring it back here for context:

@jasnell Just don't forget that this issue is about decentralized module delivery. If you think that it should be closed here based on the first message (not on the follow-up comments) and the discussion moved to nodejs/NG#26, then all is well. But please don't close the issue based on the recent discussion. I'm not saying to ignore all the discussion — I'm saying that if the discussion has gone out of hands than it still isn't a reason for closing the issue.

[ChALkeR]

@isaacs Regarding your response — I believe that the problem that I observed and why I linked your twitter here is not the npm CoC. I have nothing against CoCs, and understand why they are included to projects. The problem was in methods that you said that you are going to use to enforce that CoC, and those methods seemed harmful. I agree that this discussion does not belong here, though.

Btw, I am also fine with my comments here being deleted, if that is needed to keep the discussion on-topic.

[vkurchatkin]

Let's close this. Module delivery is surely out of scope of this repo. Interesting idea though, worth discussing somewhere else.

[jasnell]

I'm going to vote to close the issue here because there is no specific technical issue being discussed, at least not yet. For the part of the discussion involving the technical concept of building support for a decentralized repository, we have issue nodejs/NG#26 in the nodejs/NG repository. For the part of the discussion involving npm policy and how it relates to node, an issue can be opened in the nodejs/TSC repository. I will say that if such an issue is opened, however, I think we'd definitely have to ask for moderation help to ensure such a conversation stays focused and productive.

[ashleygwilliams]

also vote to close. completely agree with @jasnell's call for focused moderation as well.

[ChALkeR]

@jasnell Looks like a good plan to me, +1.

[ghost]

to everyone: if you don't like the religion, you can go and make your own.

[scriptjs]

@jasnell I understand that you want to limit discussion. This became something hairy on twitter with @issacs today. I opened the issue in Nov and @issacs closes it? This might suite him well, but does not sit well at all with me, nor the time I have taken to document it.

It appears that any time anything is said about npm, @issacs appears to shut the discussion down or other folks from NPM Inc chirp in to limit or deny the discussion. @issacs seems to create his own issues with his actions socially but this has nothing to do with this issue or why I filed it. This does not look open, transparent or inclusive and it disturbs me that this is how this has been handled.

If you want the issue reopened somewhere else, look –I have no problem with that – but please have the courtesy of including the op in the discussion and I will happily comply. My desire is to so see the issue addressed which is the purpose for contributing it. I don't want debate shut down out of the self interests of NPM Inc or @issacs trail of issues on twitter.

[ChALkeR]

@scriptjs It's not that way. It was my comment that brought this discussion to be significantly off-topic.

Also, note this is a weighted decision by several people to move the technical discussion to nodejs/NG#26 and not keep two identical issues. Don't judge by the one who pressed the button.

If you want the issue reopened somewhere else

It already is, see the link above.

[jasnell]

@scriptjs ... I'm not sure if "limiting" the discussion is the right word, it's more about wanting to keep things focused, on topic, and directed to the most productive venue where it would have the most positive impact. To be certain tho, I won't be opening the discussion in nodejs/TSC myself but anyone is free to do so and point back to this thread so the original context is maintained. I know this is an issue you feel strongly about and I don't want to discourage you from working with the community to find a resolution you are happy with, I just think we may need to find a better balance in the discussion.

[Fishrock123]

Please move any constructive discussion to NG. There isn't anything actionable for the core team here. All of us already have a lot of work and are not willing to take this idea on within an actionable timeframe.

[scriptjs]

@jasnell I agree, there needs to be balance and openness to discuss this.

That said, NPM Inc's bias is being asserted here. Hopefully, we can see a future of choice that comes from allowing open source to work without this. At present, node developers are captive to NPM Inc and their policy framework to control access to their own code. The bundling of NPM with node perpetuates this. NPM3 as a client is currently adding significantly to everyone's development time and there are more than 1800 issues filed on NPM. One needs to question whether this is healthy and in the best interest of the Node community.

New solutions are currently in the works that are already showing promising results and peer to peer module delivery will also be a option in the very near future. I hope the TSC can be open and supportive of a different future that will will have NPM competing with other solutions.