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: hal AT finney.org
  • To: bluesky AT franklin.oit.unc.edu
  • Subject: Re: Naming via SDSI
  • Date: Wed, 7 Mar 2001 00:12:29 -0800


Wei's original "three-services model" was like this:
> 1. name lookup service: maping user-friendly names/URLs to content-hash
> based ids
> 2. data location service: maping content-hash based ids to storage servers
> (network addresses and data transport protocols) that can deliver the data
> 3. data transport service: actually obtaining content from a storage
> server given its address and a content-hash based id

The current thread focuses on the first service, the one that does
name lookups.

However this model has (at least) two separate functions for the name
lookup, and perhaps it would be useful to split them. One function is
providing a "friendly name" for a document; and the other is allowing
documents to change without their name changing.

This second problem is somewhat specific to the assumption that content
hashes are the unforgeable identifiers for documents. With this approach,
any time a document is updated, its content hash and therefore its
identifier changes. Any content-hash based address will become obsolete
once this change has occured. Therefore having the name lookup service
is necessary so that you can find the latest version of the document.

However there are other ways to handle document revisions. This is part
of why Freenet has spawned its multiplicity of key (identifier) classes.
Freenet and OceanStore have identifiers which are based on cryptographic
keys and signatures. These have the same basic self-verification
properties as content hashes but they can allow documents to be updated
with the updates signed by the key.

If document changes are no longer an issue then the only remaining one
is friendly naming. There are a couple of things to note which make
this problem less severe.

First, only a very small percentage of the web pages on the net
presently have names friendly enough that they can be reasonably typed.
You might type www.cnn.com to get the headlines, but you won't type
http://www.cnn.com/2001/TECH/space/03/06/mir.fungus.reut/index.html
to learn about the mutant bacteria threat from Mir. Instead your mail
reader will treat it as a link for you, or maybe you'll cut and paste
it into your web browser.

Given this primitive level of automation, which is already necessary
for links to be passed around at all, a link with a 160 bit unforgeable
number can look like d787ef5c05460da6cf3d6aa1633655d8861e20f1 in hex or
like 14fvXAVGDabPPWqhYzZV2IYeIPE in a base-64 encoding, which is easy to
cut and paste; easier in fact than modern URLs which often span more than
one line and get forcibly line-wrapped by brain-damaged email software.

Second, of course if you are able to use HTML then the link isn't even
seen and friendliness does not arise.

The remaining case is where people do want to type a URL. This will
often be where the URL appears in print, in a magazine or newspaper or
billboard; or via some other off-line medium like radio or tv. These URLs
have to be extremely short, essentially just one or two words, something
that people can remember.

This core of the problem remains hard, but note that it will mostly
involve businesses and large organizations, and most of the cases will be
advertising. Names will typically be some easy-to-remember variant of the
company's name, or maybe a clever play on words involving its function.

It may well be that for this case a market-based registrar system will
work, with just a few large registrars handling the corporate business.
You'll have .com, .org and a few others, as we have today. Widely used
software will hardwire these popular registries and it will be no easier
to overthrow them than it is to get people to ignore the top-level name
servers today.

The result would be a two-part scheme: a relatively limited and
inflexible name system for business trademarks, which identifies the
home pages of large organizations; and a completely ad hoc system
based on cryptographically self-authorizing, random-looking names for
everything else.

Hal




Archive powered by MHonArc 2.6.24.

Top of Page