Hacker News Reader

Comment by wongarsu | Hacker News Reader

One idea that's gaining (marginal) traction in Rust (which really sits in the same boat here) is trusted reviews, where trust is established by a web of trust. You probably have some developers you trust, and they have a different set of people they trust, so you can establish transient trust (that decays as the chain gets longer).

The most relevant project for Rust is https://web.crev.dev/rust-reviews/, not sure if anything like this already exists for NPM.

View on HN

I would find amusement if the solution to the spamming of npm turns out to be a genuinely useful use case for blockchain.

> I would find amusement if the solution to the spamming of npm turns out to be a genuinely useful use case for blockchain.

I think you can implement a web-of-trust without a blockchain.

You can (because it's been done); this is a use case where "distributed but extremely slow database" is a pretty natural fit for the problem.

What advantages specifically would a blockchain have? Where does the existing solution, of using a fast database and trusting someone's private key, fall short?

indeed, blockchain makes trusting people much harder. The hijacked sense of "trust" used by the crypto-hype is a trivial technical sense in distributed databases.

Rather, an immutable ledger is a terrible system for trusting /people/, since if the data input into the system isnt reliable, there's no way to change it.

You then need to build an actual layer of trust on top of your untrustable blockchain, and then you end up spending 1MWHr and $100/review to recreate rotten tomatoes.

One of the first proposals for blockchain was a email with a minuscule, verifiable fee to make email spam uneconomical.

Spamming emails is one of the cheapest things you can do with a network connection. Even $1 per 1,000 emails would make spam untenable.

And the first proposal for proof-of-work was having emails include a proof-of-work to make it computationally expensive to mass-send emails.

I'd rather have my ISP donate 0,1 cent to some national park foundation when I send an email or whatever than have me waste power though.

Somewhat related is R's CRAN[0], which has a team of maintainers who review submissions to ensure they're up to quality standards.

[0] https://cran.r-project.org/

Aand we’re back to PGP/GPG.

https://sigstore.dev (& cosign) seem to be gaining in popularity, ease of setup, and integrations

Trust is great; but even trust can be broken either on purpose or accidentally over time. There's a great example of a well-known NPM package which was taken over accidentally by a hacker, and the thousands / millions of dependent packages and apps were totally vulnerable.

Check out https://socket.dev for a better NPM solution (not affiliated w/ them at all), though AI's definitely going to accentuate this problem 1000x.

Looks like there's an implementation of it for npm: https://github.com/crev-dev/crev

I've been willing to try it for a while for Rust projects but never committed to spending the time. Any feedback?

This sounds good. Seems like the easiest way to start is to use the package.json-defined dependencies to create the web/tree. If a developer of package A use package B, they trust the developer of package B, and so on.

I would love to see this getting bigger, not just for package managers but in general. With AIs it will be easier than ever to produce spam or just poor content. We need some better way to rank and accept content, and apart from having large tech companies hiring armies of reviewiers, I would think web of trust can solve it.

Don't think that requires blockchain per se, or even human verification. It would work quite well just for me to assign my trust to various identities (Github accounts, LinkedIn accounts, etc) and for that trust to be used when ranking or filtering content.

I don't entirely get this. By adding a dependency to a project, doesn't that already establish a web of trust? I.e. if you trust the dev who made library X, you trust they have good reason to trust library Y that X depends on, etc.

Is this just about being more explicit about review?

Reply on news.ycombinator.com