[edit]

1 Distributed Hash Tables

... are a fancy P2P concept for mapping keys to values on a global scale using a redundant decentralized network of servers, sort of a generalized domain name system to serve all sorts of purposes. Can also be used to map things to IP numbers without resorting to DNS or a huge centralized look-up server.

DHTs would probably work best when created by a group of nodes in a trust relationship with each other, but apparently this hasn't been tried. DHT technology usually works in an open network where attackers insert themselves into the system and try to disrupt it. Modern DHT technologies can handle such forms of attack and learn to route around them (see GNUnet's DHT for example).

[edit]

1.1 DHTs for PSYC

PROs

  1. When employing DHT for node discovery, it frees us from the burden of needing a domain name. Instead we can use any string, keyword or public key data to point to our current IP. This is great for P2P use as we don't need to implement a dynamic DNS strategy.
  2. Since the DHT itself is intelligent code it can doublecheck the legality of operations (like certain type of entries in the hashtable can be access protected), maybe even apply trust metrics to ensure subscription operations are trustworthy.
  3. Crypto provides the most obvious form of access control: The entry of a certain public key is owned by the public key itself, meaning that only who owns a copy of the private key can edit it. Routing by public key sweeps out all troubles of risking all kinds of MITM attacks as the powerful implementation in Tor's hidden services has publicly proven.
  4. The DHT nodes themselves could act as context masters in a distributed multicast scenario, or they can point to one or more context masters, allowing for redundancy in context organization.
  5. DHTs are a way to avoid single points of failure, like depending on your home server in PSYC's current federated architecture. See also PSYC2.

CONs

  1. Unless you make the DHT entry point to the UNI server, you don't get to have a concept like the UNI, which handles things for you no matter if you are online or not. If you do make it point to the UNI, you have the disadvantage of a more complicated look-up scheme than just using DNS and uniforms. We have to use persistent pubsub channels instead.
  2. In order to leave a message for somebody, anyway, you need to register a "server" node that is willing to store messages for you in your absence. One way to deal with this is to have both UNI and current UNL registered in the DHT. No wait, with PSYC2 we register an entire channel whose agnostic relays will keep the messages.
  3. Your application needs to know some DHT nodes to start off from, which will tell you which nodes you should register with and which nodes know about your friends. This bootstrap necessity can become an issue for security and privacy. PSYC2 can bootstrap over the social graph instead.
[edit]

2 See also