Spore – Decentralized package manager on Ethereum and IPFS | Hacker News Reader

Spore – Decentralized package manager on Ethereum and IPFS

github.com

45 pointsjamesdwilson21 comments

AppFS ( http://appfs.rkeene.org/ ) is exactly a decentralized package manager, except it uses HTTP as a transport and does end to end verification (i.e. not like HTTPS where only the transport is verified) of all data using PKI.

Can somebody ELI5 why we need Ethereum, too?

So you can program your program's program while you program

I got it. Gx [0] looks simpler and better without the craptocurrency stuff.

[0]: https://github.com/whyrusleeping/gx

  $ gx import QmR5FHS9TpLbL9oYY8ZDR3A7UWcHTBawU1FJ6pu9SvTcPa

  $ spore install mortal

This is a very important distinction that you gloss over when you use loaded terms like "craptocurrency".

Everything comes at a price. The first one is free and has a lot fewer dependencies to be used and operate - no Chinese miners required!

Why do you want to go down the rabbit hole of economic externalities?

Do you realize the sorts of unnecessary energy that is wasted just to protect the legal and financial infrastructure that even let's a company like npm exist in the first place?

You're making it seem like only cryptocurrencies have a downside. The truth of the matter is that there will always be a price to pay for state-making functions and that we can't build npm-like things without these state-making functions.

Cryptocurrencies might end up being one of the least wasteful manners in which a group of people can come up with decentralized consensus.

Someone should do a study to compare the infrastructure required to support storing and tracking all of the world's real estate property titles versus the infrastructure of all the Chinese miners in the world. I'm willing to bet that in kilowatt hours even the heavy-duty Bitcoin blockchain is much more efficient.

I don't have any interest in anything with a speculative value. Sorry, but Bitcoin didn't make it - "the next big thing", i.e. Ethereum will not make it either as people have zero interest in something that's at the mercy of low-quality speculators. In this case, I really don't want my business to have anything to do with a speculative technology. As I said, the only two requirements are authenticity and immutability and you don't need Ethereum to implement it.

Don't only think of it as having a speculative value. Think of it also as having the utility of being able to write to an immutable public ledger. Think of "Bitcoin the currency" as a commodity that lets you write to the Bitcoin blockchain like how ink is a commodity that let's you write on paper.

You don't need to use much Bitcoin in order to secure a lot of data with a timestamp and signature. This makes it great for synchronizing all sorts of transactional data across service boundaries meaning people can bring their ownership rights from provider to provider.

With something like keybase.io you're reliant on them to authorize the link between a name and your public key. You're also reliant on the DNS system. All of this adds unnecessary friction to the concept of individual ownership of digital properties like domain names to say nothing of owning the rights to a named module of published open source code.

The speculative value is what drives the mining process. It's a dirty little trick and yes, it encourages a bunch of people near cheap hydro power to buy a bunch of machines that do nothing other than play the SHA-256 lottery.

You can still have zero interest in the speculative value of Bitcoin. That's the miners concerns.

Your concerns can just be the transactional fees that let you embed your own data in the consensus ledger.

You need ethereum (or some other blockchain) if you're concerned about hackers. You could imagine an attacker getting into npm's servers and replacing package links with malware.

You might also like a decentralized repo if you're worried about a single agent having a monopoly. This monopoly could one day charge for access to the repo.

That's a total overkill for the purpose. We use signatures for authenticity checks. Let's not try to use Ethereum for everything just because we hold some ETH and want its value to grow by using it where it's not even necessary.

Decentralized consensus over which private keys own what strings (aka Namecoin) would save us from having to deal with obtuse hashes, would it not?

Once I install a package, its hashes and other info become part of the project. I just don't want that to change in time without me knowing. Etherum here is an overkill, it's not practical.

How do you first discover the hash? How are you looking it up?

The recent issue with NPM surfaced the following two major issues:

- a package got unpublished - we demand an immutable package manager;

- packages got hijacked - we need authenticity as basic as checksums or signatures.

Anything that accomplishes the above in an uncomplicated manner will win my business. Any craptocurrency pitching will not.

gx seems to solve this with the concept of "repositories". From the gx README:

> gx supports named packages via user configured repositories. A repository is simply an ipfs object whose links name package hashes. You can add a repository as either an ipns or ipfs path.

It doesn't solve the repository "discovery" problem, but it does seem conceptually much simpler than trying to use a cryptocurrency-based solution.

So npm install --save $pkg $sig?

Which means I have to look up the signature every time, and which point I might as well just install using the github repo. The fact that pretty much nobody uses that workflow today tells you something.

If its the token that bothers you, run this off the main chain with the transaction cost set to 0. No ether necessary.

Sorry, that's probably just me, but I don't wanna use anything that relies on Chinese mining operations!

You don't need miners at all, if you're not worried about censorship resistance. You can use Ethereum with a single validator. That means you don't need a token (ether) and you get instant transactions. Plus it prevents the hacker issue above.

How a single validator any better than relying on, let's say, Keybase?

Not sure how that would work, but I don't know much about Keybase.

Reply on news.ycombinator.com