I don't believe anyone ever said it was. It's a far better approach than using shasums for package integrity though.
>Proxying via a local dependency is a good practice, but that can be set up independently of npm.
That's the point. I see a lot of people hand wringing about removed modules in the future. It's not NPMs job/obligation to provide the javascript world with never ending storage, hosting, and bandwidth. Expecting a third party to host dependencies that make in house apps run is a fool's errand. That strategy can, will, and just did fail.
> It's a far better approach than using shasums for package integrity though.
The point of that article is that it isn't. It only adds integrity if you trust the signer. From the article:
> When attempting to verify a signed file you check the signature against a public key. If the signature matches that public key then everything is kosher. The question then becomes which public key, and therein lies the rub. If you do not have a well defined model of trust then all you’ve done is thrown cryptography at a problem in order to give the people involved the ability to say that their system has signature verification.
> It's not NPMs job/obligation to provide the javascript world with never ending storage, hosting, and bandwidth.
That's true, and a good point that we shouldn't expect it to be this way in all circumstances. On the other hand, allowing people to rip out packages without warning makes for a much worse npm experience. Expecting that all JS developers set up a local proxy for all projects, particularly in a non-professional setting, is also unrealistic. npm is indeed improving the situation here (even if they're not solving all possible situations).
Do you think if would help if npm automatically banked packages locally? It's not quite a company-wide proxy, but it could prevent this from failing on your local machine without too much setup.
>The point of that article is that it isn't. It only adds integrity if you trust the signer.
Simply put, that article is wrong. Trust is not a binary. It's greyscale. While no one ever achieved perfect security, pretty good security is better than none at all.
I find it amusing that this article is published using https, that the certificate is from Let's Encrypt, and Let's Encrypt validates CSRs using an unencrypted side channel (DNS). I mean, what a hypocrite, right? There's a potentially easy exploit in his system and I doubt any of his readers will ever contact him in a secure way to verify his key fingerprint. Why doesn't he now eat his own dog food and just give up and go with http instead of going to the trouble of renewing a certificate every 90 days? By the logic in his article, how can I even trust he published any of that stuff?
Even if the answer to "which public key?" is "the same public key that signed the original version of the package we downloaded when we first added the dependency", that does add something.
It appears that by publishing, you accept their terms in allowing them to distribute the package [1]. They also say they won't run the code directly (although they may analyze it), which might sidestep certain license issues. My guess is that it's no different than posting it on your own website and having the Internet Archive back it up.
(IANAL. Just doing my best to interpret their policy.)
FWIW unlike HN, downvoting has no negative consequences to the comment on GitHub. It's useful on HN to effectively remove the off-topic and deeply non-constructive comments. But on GitHub, it serves no such function. We're going to end up with the many abuses of -1's and none of the benefits.
As for "I don’t think it’s 100% clear-cut that you should never ever implement downvotes," perhaps. There's still probably better ways to flag inappropriate comments though. Like a flag button. Downvotes are far too general and ambiguous in comparison.
The difference is when you +1, you're publically expressing agreement with what they wrote. If someone you like writes something you don't agree with, you wouldn't +1 them. If you're having a good day, you still wouldn't blindly dish out +1's because if you +1 a controversial comment, it could hurt your reputation.
Negation is different because it's entirely ambiguous. You can dish them out freely and retroactively rationalize your intention. -1's are way more susceptible to knee-jerk emotional reactions than +1's.
A relevant example. Think of the political candidate you like the most. If someone you really like asks you to +1 a persuasive argument about their competitor, would you? On the other hand, if they asked you to -1 someone, you probably would. Even if you knew very little about them.
My experience of open source projects is that people dish out +1's freely and are reluctant to -1 as it signifies conflict. +1 is arguably the more ambiguous for that reason as it can mean "I didn't read the issue but I like you and what you're saying at a glance looks non-insane" or "meh" or "I love it". You're really underestimating the ammount of politics that can factor into these things, people will +1 something that they 90% disagree with because of who's saying it, don't kid yourself otherwise.
Nobody really cares if you +1 something crazy, maybe you were just feeling agreeable that day, or you misunderstood the comment. But if you -1 sensible things you're going to get a bad reputation pretty quickly.
That's because people don't tend to write "-1", but rather disagree with a comment explaining why. GitHub is full of disagreement. We'd be in a much worse place if that was all expressed through downvotes instead of comments (unless of course, an issue is explicitly opting in to a vote).
> people will +1 something that they 90% disagree with because of who's saying it, don't kid yourself otherwise.
Ok yeah, you're right about the politics. Bad example. But in open source, I've seen much more comment-based pushback regardless of author.
Sounds like a pre-optimization. You can get the same level of information with two comments and vote exclusively with +1's, but without the general negative aspects of what's mentioned above.
Right, if you're asking every single issue poster ever to remember to post two comments specifically for voting, versus just posting their issue itself.
Not every issue needs an up/down vote. But with the addition of -1, all issues and _all comments_ on those feature requests now have one. Which takes us back to the negative consequences outlined in this thread.
If I left the above with no further explanation, it doesn't give you any signal as to why I disagreed with you. One the other hand, if we were having this conversation on GitHub, people who agreed with my counter-point could react with a +1, giving you a much stronger signal about what exactly the disagreement is about.
And once someone provides a valuable counter-argument, it's no longer "rigged toward agreement."
Compared to an explanation with several +1's, a drive-by -1 adds virtually nothing to the discussion because they carry so little information.
Not everyone has to give a signal on why they disagreed with you as much as people don't have to give you a signal on why they agree with you. I don't get this argument. People may agree with 2 out of 5 things in a list and vote +1 because they don't care about the 3 other things. You still don't get that feedback from a +1, just like you won't get from a -1. There shouldn't be higher standards for disagreement based on reasons because the same doesn't exist for agreement.
> Not everyone has to give a signal on why they disagreed with you
On GitHub? They absolutely do. It's a platform for collaboration, not idle chatter. If you do not wish to support your disagreement, you probably shouldn't be posting anything there to begin with.
EDIT: I've also already explained to you why 'agreement' and 'disagreement' are held to different standards. I'm not sure why you keep repeating this point.
moe is right. And what is strange is that you keep repeating yourself.
They absolutely do.
No, they absolutely don't--GitHub says so. You think they absolutely should have to, but they do not.
Here's an example: Alice posts a feature request on the issue tracker for Project Awesome saying that the project's mascot should be changed to a unicorn. Bob downvotes it. Neither person has provided an argument for their position.
According to you, Bob is required to explain why he doesn't want a unicorn mascot, but Alice doesn't have to explain why she wants one.
You are assuming that a positive argument will always be made in support of an assertion, and that therefore a negative argument must be made against it rather than merely a contrary assertion.
But it often happens that the pro side of an issue makes unsupported assertions and unreasonable claims, then the con side makes reasoned arguments, and the pro side proceeds to ignore the points raised by their opponents.
The real problem is anonymous voting. Anonymous votes are not very useful, because for all you know, the person voting doesn't even use the software in question. Voting within a team of collaborators could certainly be useful, even without substantiation, but "drive-by" votes by random Internet people are the problem.
EDIT: Ironically, this downvoting of moe's and my comments proves our points and demonstrates why anonymous downvoting is a problem. "We should only have reasoned arguments!" they say. But when reasoned arguments are presented in opposition to their claims, they merely downvote rather than making a reasoned counterargument. They do not do as they say.
And since the cost (in time and effort) of their anonymous downvote is far less than the cost of writing a rational counterargument, the level of discourse is driven further and further down as those who are willing and able to argue their positions rationally are discouraged from doing so. Why waste your time arguing with people who do so in bad faith?
Sorry for any confusion; this wasn't my work. I only shared it on HN. Nathan LaFreniere is the author of this post and project (https://github.com/nlf).
I'm sure there are more direct examples, but I watched a video about Sesame Credit recently and it paints a rather dystopian picture of what's possible when you mix surveillance and gamification. https://www.youtube.com/watch?v=lHcTKWiZ8sI
I've observed a similar effect in my own work. I wonder if it's as simple as the capability to produce more smaller projects and fewer large projects. Curious if you produced a lot of smaller projects before having valuable ones.
Proxying via a local dependency is a good practice, but that can be set up independently of npm.