I hoping for some enlightenment.
The way I perceive the programmable blockchain that ethereum will provide, is that you could build:
- Distributed DNS with an expandable backward compatible API
- A distributed twitter using the DNS for naming and torrent for message storage like twister
- A distributed FaceBook, with the naming and authentication looked after by ethereum and also distributed storage
Help!? My brain hurts
2 ·
Comments
I think you're correct about all three. There are, however, two 'gotchas' I can think of:
1) Speed. A basic distributed DNS would be just a sequence of key/value pairs, but the contract per say could grow incredibly large. Then there's the fact the contract storage compression seems to be done via delta between blocks (again I need to research this further) so lookups might be slow. Not exactly the ideal environment for low-latency stuff
2) Data sizes. Linked to the above point of course, but there's a reason why Twister doesn't store data on-chain This of course adds complexity to the project, but also potential for value add with future developments.
I think as we try to actively code all these things we're going to hit some small roadblocks. The distributed dropbox idea listed on the official site has a bit of a hole into it for example, namely that nodes have a vested interest in holding a file long term but no 'obligation' to do so. Meaning, the file could eventually disappear for good. These things I'm sure will be ironed out in time, but will require new thinking around decentralised apps.
One of the first apps would be a quite simple data-store service with its own currency.
If I want to earn money for storing other people's data, I simply put down an escrow, and get money for stored data based on data size and time and/or used bandwidth. If I'm about to terminate serving stored data, the network makes sure there is somebody taking my place, then I get back my escrow.
Making sure the node still has my data can be implemented with the nodes challenging each other for the data. (or even better, hashes of ad-hoc slices of the data)
When I want to store something, I encrypt it (optionally), and request a number of nodes to store my data, and pre-pay the fee. I can choose how many nodes I want to play with.
Once this is stable and secure, one can build all the fancy apps using this service with a simple api, solving most storage-related problems for good.
Other things to think about is, does the user want to store the data at a node close by (so it's fast) or far away (so it's safe from local government, or a war zone). Or does the user want to fragment the data everywhere.
Regarding DNS, It would have to be cached to be useful, which is how it works now to some extent. That could be distributed too, with small fees to nodes. You could request from multiple nodes, to make sure your getting a trusted result.