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.
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.
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.
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.
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.
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.
21 comments
[ 2.5 ms ] story [ 57.9 ms ] thread[0]: https://github.com/whyrusleeping/gx
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.
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 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.
- 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 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.
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.