DHT usage and requirement lists

"pwang708" <[email protected]>
Newsgroups gmane.network.gnutella.devel
Message-ID <[email protected]>
Updated based on Arne and Michael's comments. Some of them will be
hard to achieve but we still put them here for completeness. Please
feel free to edit and/or put new sections.

Usage:
1) magnet links
2) push-proxies
3) alt-locs
4) searching for files by hash. 
5) Searching for file metadata by its hash. 
6) serving as distributed trackers for bittorrent enabled clients. A
DHT can also be used to search torrent files.
7) helping Gnutella for rare keyword searches. 
8) serving as a decentralized contact-list so that one can search for
specific users
9) searching for my friends' addresses or their Ultrapeers' addresses.
Connecting to the same ultrapeers as my friends (and their friends)
might allow me to find interesting files in fewer hops, which is good
for two reasons: less bandwidth used, and fewer non-friends (potential
spammers) reached by the query.
10) We can group peers having common interests and tag the groups. A
group can publish the tags and a subset of current ultrapeers in the
group into the DHT. A node can search the tags to join the group or to
find files available under the tags.


Requirements:
1) Good user experience 
2) Low overhead.
3) Hotspot mitigation.
4) Write Quota system. A user can only publish a certain number of
data items, to each DHT node.
5) Data security. E.g., only I can modify my push proxy information. 
6) Mitigation of "traditional" spams. I quote a line from Arne's
previous post: "Spam, in the way it is used today, is a means to make
it harder for people to reach some popular files for whose
"protection" the spammers get paid." I think we should use some other
name (such as targeted file poisoning/pollution attack) to distinguish
it from "traditional" spams. 
7) Index poisoning/pollution attack mitigation.
8) Routing security. I.e., always be able to find the replica roots. 
9) A richer API. The DHT can be used for several things which may have
different requirements. E.g., allow users to define their data's life
time in [MIN, MAX], which are network wide parameters.
10) fixable lookup. For example, for lookups we don't care about
speed, parallelism = 1, else parallelism = 3; exhaustive or not (find
all replica root or find a node who answers a query); caching replica
sets so that republishes consume less bandwidth... 
11) Identification system.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.