3 ms·

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.

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/ https://web.crev.dev/rust-reviews/, not sure if anything like this already exists for NPM.

Mayzie 4y ago
Aand we’re back to PGP/GPG.
- verdverm 4y ago
  https://sigstore.dev https://sigstore.dev (& cosign) seem to be gaining in popularity, ease of setup, and integrations
sokoloff 4y ago
I would find amusement if the solution to the spamming of npm turns out to be a genuinely useful use case for blockchain.
- lelanthran 4y ago
  > 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.
  - sokoloff 4y ago
    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.
    - overthrow 4y ago
      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?
  - mjburgess 4y ago
    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.
- mindcandy 4y ago
  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.
  - wongarsu 4y ago
    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.
    - rightbyte 4y ago
      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.
sgu999 4y ago
Looks like there's an implementation of it for npm: https://github.com/crev-dev/crev 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?
ripperdoc 4y ago
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.
dpkirchner 4y ago
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.
jcalabro 4y ago
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/ https://cran.r-project.org/
rendaw 4y ago
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?
transitivebs 4y ago
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 https://socket.dev for a better NPM solution (not affiliated w/ them at all), though AI's definitely going to accentuate this problem 1000x.

Mayzie 4y ago

Aand we’re back to PGP/GPG.

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

sokoloff 4y ago

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

lelanthran 4y ago
> 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.
- sokoloff 4y ago
  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.
  - overthrow 4y ago
    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?
- mjburgess 4y ago
  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.
mindcandy 4y ago
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.
- wongarsu 4y ago
  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.
  - rightbyte 4y ago
    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.

sgu999 4y ago

Looks like there's an implementation of it for npm: https://github.com/crev-dev/crev 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?

ripperdoc 4y ago

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.

dpkirchner 4y ago

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.

jcalabro 4y ago

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/ https://cran.r-project.org/

rendaw 4y ago

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?

transitivebs 4y ago

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 https://socket.dev for a better NPM solution (not affiliated w/ them at all), though AI's definitely going to accentuate this problem 1000x.