Skip to Content.
Sympa Menu

bluesky - Re: Naming via SDSI

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: Brandon <blanu AT uts.cc.utexas.edu>
  • To: Global-Scale Distributed Storage Systems <bluesky AT franklin.oit.unc.edu>
  • Subject: Re: Naming via SDSI
  • Date: Tue, 6 Mar 2001 21:09:25 -0600 (CST)



> How would that work in a P2P model? If we did have competing name lookup
> services (using Wei's term from the three service model), would there
> have to be some global mechanism to make sure that no two services tried
> to handle the same addresses? Or would we accept that address to name
> mapping was inherently ambiguous? Or, perhaps, would TLDs have to have
> unfriendly unforgeable names?

Well, I see three ways to handle this: central authority to resolve
disputes, choosing sides, or total subjectivity. Pet names is total
subjectivity. I think that's a pretty good system. It's the system I'm
using to do e-mail over Freenet (PGP fingerprint == key, Freenet "e-mail
address" == pet name).

My main issue with total subjectivity is that it requires that you pass
around fat references (keys) all the time. So I can't tell someone "Check
out megatokyo.com." I have to say "check out
asjldkq9u4q8412093ajla0912l". It helps if you have a computer-mediated
communication environment to do translation for you, but it sucks for
voice and written. I know the last time I wrote down my PGP fingerprint I
made to copying errors. If it was a different kind of key, such errors
woul have made it useless.

Having naming paths helps because then, for instance, I can run a name
mapping service and if you already have my key then I can tell you "check
out brandon/megatokyo" and that path will resolve. It still has the same
theoretical problems, but in practice will suck less because you tend to
communicate with the same people a lot.






Archive powered by MHonArc 2.6.24.

Top of Page