The need for a DHT

[indolering]

As some of you know, I've been working on a pure client-side/in-browser Javascript resolver for Namecoin which avoids all of the legal problems inherent with proxies and mirrors. So far, I've been planning on using various sources for routing information, such as Github, Facebook, etc. This is primarily to enable websites to provide custom entry points for users: you can't censor an IP/URL if you don't know about it! It also has a promotional side-effect of sharing/liking a page on a social-networking site which provides DNS routing information (yes, it's secure and it will work).

However, in order for .bit to be suitable for every-day use, it's abundantly clear that we need a decentralized mechanism which vanilla browsers can use to get the DNS information in a way that doesn't require any user interaction. We need a DHT which can return DNS records.

I'm a web-hacker/usability/psych person (my client-side router is stretching my programing abilities as is) so I'm not entirely sure of the best way to go about all of this and it would certainly require a lot of hard work for the core developers. I would not bring this up for debate if I didn't think it was critical to .bit's future: we have to break the chicken-egg problem of adoption before we can get the DNS players to think about accepting .bit as a legitimate root authority.

A browser/web accessible interface would eventually allow us to route around application-level IP and URL blacklists entirely: there are already multiple browser-based/WebRTC P2P CDNs (peercdn.com, peerjs.com). With a DHT a client which could see any visitor of a given website would be able to load that website regardless of whether the URL and IP's are blocked in the client's home country. Yes, there are security and about 100 other issues to be worked out, but all the parts have already been implemented in one form or another (crypto.stanford.edu/flashproxy/ <-pure JS) and it can be done securely.

I would think that it would probably be easiest to start with just adding DHT capabilities to namecoind and/or some popular mining client. Miners are ideal bootstrapping nodes as they are non-transient participants which join the network in a decentralized manner and are not under the control of any one person.

I think I've said enough and I hope I don't come across as too ambitious.

[domob]

I have to admit that I've not yet fully understood what you are up to; and also do not know all the details about DHTs. But have you looked at the idea proposed by snailbrain here: https://dot-bit.org/forum/viewtopic.php?f=5&t=1388 This would be another way to implement a light client with secure and trust-free name resolving, which seems to be (roughly) what you want to do. Would that be a solution to your problem? If not, can you please try to clarify what you need in more details (so that I can understand it )?

[indolering]

I need to be able to make a GET request for DNS records. I have a hacked XML-RPC and PHP bridge setup right now, but we need something that is decentralized: bootstrapping nodes which are not under the control of any one organization.

A DHT is basically the short-term memory version of a blockchain but sharded probabilistically across nodes. Each node has a set of HashID<->IP mappings to other nodes in the network. The HashID's are distributed such that nodes are more likely to carry the routing information for similar HashID's. If the first node you contact doesn't have that exact IP<->HashID mapping, it will give you the address information of the most similar HashID it knows of, ensuring some upper limit on the number of network hops required to get across the network.

Much of the functionality overlaps with namecoin, the difference is that DHT's are meant to forget things very quickly and distribute network load evenly whereas namecoin stores copies of the same material for long periods. We need to be able to circulate IP addresses of different nodes on the network from whom we can query for the static DNS information.

There is a bunch of legal stuff I need to clear with a real lawyer before I can go into detail on it here ... we don't want to have something twisted around later in court.

I'll explain more of jsDNS as soon as final are over : )

[virtual_master]

As some of you know, I've been working on a pure client-side/in-browser Javascript resolver for Namecoin which avoids all of the legal problems inherent with proxies and mirrors. So far, I've been planning on using various sources for routing information, such as Github, Facebook, etc. This is primarily to enable websites to provide custom entry points for users: you can't censor an IP/URL if you don't know about it! It also has a promotional side-effect of sharing/liking a page on a social-networking site which provides DNS routing information (yes, it's secure and it will work).

However, in order for .bit to be suitable for every-day use, it's abundantly clear that we need a decentralized mechanism which vanilla browsers can use to get the DNS information in a way that doesn't require any user interaction. We need a DHT which can return DNS records.

I'm a web-hacker/usability/psych person (my client-side router is stretching my programing abilities as is) so I'm not entirely sure of the best way to go about all of this and it would certainly require a lot of hard work for the core developers. I would not bring this up for debate if I didn't think it was critical to .bit's future: we have to break the chicken-egg problem of adoption before we can get the DNS players to think about accepting .bit as a legitimate root authority.

A browser/web accessible interface would eventually allow us to route around application-level IP and URL blacklists entirely: there are already multiple browser-based/WebRTC P2P CDNs (peercdn.com, peerjs.com). With a DHT a client which could see any visitor of a given website would be able to load that website regardless of whether the URL and IP's are blocked in the client's home country. Yes, there are security and about 100 other issues to be worked out, but all the parts have already been implemented in one form or another (crypto.stanford.edu/flashproxy/ <-pure JS) and it can be done securely.

I would think that it would probably be easiest to start with just adding DHT capabilities to namecoind and/or some popular mining client. Miners are ideal bootstrapping nodes as they are non-transient participants which join the network in a decentralized manner and are not under the control of any one person.

I think I've said enough and I hope I don't come across as too ambitious.

May be I didn't understood what do you intend to implement.
Do you want to make a distributed content storage around Namecoin like GnuNet, Freenet or Retroshare ?
If yes I was also thinking about this.
But :
1. When Tor I2P and Freenet addresses will be resolved with .bit entries what would that bring ?
you can save the distributed content with this already existing systems and link from a .bit domain.
2. To resolve a domain with DHT you still a light client which has the DHT hashes or root hashes.
And if you have a light client in the browser then you can already resolve the domains with it without DHT.
3. You are already able to store DHT keys from the client in a namespace what you choose for your application.

[indolering]

No, it's not a permanent information store, just a way to disperse responsibility for short-term routing information. The bootstrapping nodes would hold relatively recent adds to network, nothing like Freenet.