Here's a cool example of a
useful smart contract app
http://www.blocktech.comusing ipfs/bitcoin/ether/florincoin/etc.
I'd use it anyway.
Sorry but afaics that sucks.
I can't find any mention of how it uses Ethereum? Appears it is using Florincoin. If it is using Ethereum, that doesn't mean Ethereum can scale decentralized (which I have already explained it can't!).
Nevertheless, there are other flaws in this Alexandria project.
1. It is relying on IPFS, which is a decentralied file storage system. IPFS is interesting for orthogonal reasons (which I will discuss below), but there is an insoluble flaw of decentralized file storage in that copyrighted content illegally distributed without compensating the copyright owner, can't be forceably removed from all nodes, and thus the protocol ends up banned by hosts[1]. Not only is it economically and technologically unrealistic to fight the enforcement of copyrights by having users stand up their own nodes connected over asymmetric upload bandwidth of home ISPs[1], but it also deprives all of us of the Knowledge Age decentralized economic ecosystem and social networking we will need to implement the Knowledge Age devolution of the corporation (see the last link in [1]). Note it might be possible to design a decentralized file storage system that enforce removal orders and enforced per-per-download royalties to the copyright holder, it is impossible for these decisions to be made without centralizing the control over these decisions. I suppose one could dream up a design where all the nodes voted and reached a consensus about each copyright claim, and the participants would be motivated to do the right thing so as to avoid the protocol being banned/regulated by government, such a design is going to
suffer from unbounded preemption and thus
will need to use centralized trust, so it is right back to being centralized after all.
2. In the video for Alexandria, note how he pins the files to his local computer in order to attain free access. But as soon as he has done downloading, he can unpin and thus he has given nothing to the network if no one has downloaded the pinned files while he was downloading them. For this and other economic/marketing/technical reasons, the aims of this project are unrealistic and insoluble.
Regarding IPFS, I read some of the white paper and viewed some of
the video presentation (which I highly recommend) and about 17 or 18 minute point it gets into the key points I want to share my analysis on. So I entirely agree with the creator of IPFS (Juan Benet) that resources should be referenced by hash rather than by URLs. As even he points out in his presentation, that is orthogonal to whether there is a decentralized protocol for storing these resources (and add my point that storing on home user's P2P servers such that copyright and royalties can't be enforced). And I entirely agree with him that we need a way to declare resources as immutable so they can be cached nearest to the use, which is needed both by offline use cases and to minimize redundant transfer of content (and Juan makes the astute point that bandwidth is not scaling as fast as storage nor CPU computation ... and I would draw the analogy to that the Scrypt paper also points out the same for RAM latency not scaling as fast as RAM storage and speed).
So how to we reconcile these needs and the issue of needing to enforce copyrights? We need a decentralized protocol because we don't want to rely on any one host or federated collusion of them (and also to wrap high availability and optimization in an algorithm/protocol versus inferior/non-interoperable adhoc solutions), and we need to record the copyright parameters in a block chain. But how can the block chain verifiers determine whose claim to a copyright is valid? I don't think there is an algorithmic way yet to determine for example if two songs are close enough (including for example in the case of musical content, DJ mix songs that resample other songs) in content to be a copyright violation? If there was, we could have a rule that the first person to sign a hash of content (and submit it to the block chain) is the copyright holder. But change even one bit of the content and the hash of the content changes. I believe there can be an algorithmic solution probably drawing from existing technologies that have not yet been applied to this problem. So then we'd need a way for the copyright holders of existing works which are already public (so any one could submit the hash to the block chain) to prepopulate their hashes on this block chain.