Re: Re: DHT usage and requirement lists

pwang708 wrote:
> Good point! I am not sure about the cost. This is what I am thinking
> though: the DHT distributed tracker is a backup of a traditional
> tracker. Besides, once a peer connects to others in the swarm, they
> can start to use peer exchange protocol to learn more peers in the
> swarm. A distributed tracker can be sloppy in this case...  Need more
> analysis... Any idea?

Perhaps distributed tracking is just a special case of finding download
sources - that is, find a few sources through the DHT and then use peer
exchange (BT's equivalent of the download mesh) to find others?

Does a distributed tracker do anything else apart from peer discovery?

> How about we change it to all the friends + people from who we
> downloaded files before.

Sounds like a good idea to me. We might want to retain a list of the
files we've downloaded from each peer, so that users can manually delete
peers who've provided mislabelled or harmful files - otherwise the
effect of a single harmful download is magnified as we'll keep searching
the same peer in future.

> To be able to authenticate a node. NodeID generated randomly or NodeID
> = hash(IP/port), or = hash(public key), or = hash(public key,
> IP/port), etc. It would be better if we can have a certificate
> authenticity. If I remembered correctly, Credence needs a certificate
> authenticity.

Hash(public key) might be best, since the IP/port can change regularly.

I'd like to avoid relying on a central certificate authority if
possible. Does Credence still need a certificate authority if we store
the ratings in the DHT? I'll re-read the paper...

Cheers,
Michael