I don't understand much about the blockchain, but one thing I have heard is that it's impossible (or very hard) to remove things from it. It is immutable, sort of append only, if I understand it correctly. So my question is, is there anyone working on moving npm to the blockchain? Or doing something like a package manager on the blockchain? If not, why not?
No. That's not what I'm talking about. That's just a way to host your own snapshot of the entire npm registry. Not a good way to introduce the decentralization feature of IPFS.
You don't need a full blockchain for this: the relevant property is (somewhat tautologically) that it's an append-only data structure. By convention, everyone processing the blockchain looks to make sure that the new blockchain they get is a descendant of the previous blockchain they already have.
There are lots of other structures that work like this. Git is one - when git fetches a branch, git will check whether the remote branch includes all the commits it saw last time it fetched, or some are missing. (By default this is non-fatal but tends to produce warnings/errors when you try to actually use the replaced branch, but you can easily make this fatal.) Another good one is the style of Merkle trees used in Certificate Transparency: there's no proof-of-work, so the trees are small, but they still include a cryptographic hash of each previous tree so you can detect if something has gone missing.
The other relevant property of the blockchain is that it's not a reference to data elsewhere, it (like git) actually contains all the data that's ever been on the blockchain, and you need that data to verify the blockchain properly. This may or may not be what you want for a programming language package manager; it means that in order to set up a new development environment, you have to download every version npm package that ever existed. It does accomplish the goal of preventing things from being removed, but it's pretty heavy-weight.
> By convention, everyone processing the blockchain looks to make sure that the new blockchain they get is a descendant of the previous blockchain they already have.
This is not true. Bitcoin-esque blockchains are NOT append only. The only thing clients do is: 1) ensure the blockchain they have received is valid, and 2) that it is longer (more total PoW). If those conditions are met, they will consider that new chain the current chain.
You can come up with a new, completely different sequence of blocks, send it to clients on the network, and get them to start using that new chain instead as long as it has more PoW.
Oh, right. That seems like not a property you want in software releases - there shouldn't be a possibility of getting spoofed data (or metadata), either you get a signed release or no release at all. Bitcoin needs that because there's no signing authority.
The key thing here is that there is an obvious central authority for software releases (the NPM registry, or GitHub, or Debian, or whatever), so proof-of-work-style systems are overkill because you don't fundamentally need decentralization. You could imagine some sort of decentralized first-come-first-serve software registry, but that doesn't seem obviously better than a central one.
