DNS, Twitter, FaceBook...

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

Comments

  • StephanTualStephanTual mod London, EnglandMember, Moderator Posts: 1,282 mod
    Hi Mark,

    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.

  • lezlez Member Posts: 2
    My vision is:

    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.
  • StephanTualStephanTual mod London, EnglandMember, Moderator Posts: 1,282 mod
    Lez that actually sounds like it could work - love it!
  • FlappySocksFlappySocks Member Posts: 3
    I like the escrow idea. One of the problems with distributed storage, is quality of service. Your going to get users with poor internet connections renting out their hard drives, alongside those with dedicated hardware in a datacentre. It would be good if those with the best hardware, get the most reward.

    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.
Sign In or Register to comment.