[p2p-hackers] Re: [decentralization] The Content-Addressable Web

Gordon Mohr gojomo at bitzi.com
Thu Oct 25 12:47:01 UTC 2001


Mark Baker writes:
> > The use of URNs allows advanced caching techniques to be
> > employed, and sets the foundation for creating ad hoc Content
> > Distribution Networks (CDNs).
> 
> Untrue.  The use of URIs allows these things.  There is nothing
> special about URNs in this respect.

Well, I belive the theory is that URNs have slightly stronger 
"identity" characteristics. However, the latest W3C "clarification"
seems to simply confirm the practice of using some URIs as if
they were URNs.

> > * It is ill-advised to retrieve content from an untrusted
> >   cache, because it can modify/corrupt the content at will.
> >   This severely limits the utility of cooperative caching
> >   systems.
> 
> Not to my knowledge.  Either you trust the provider of the cache,
> or you don't.  If you do, you can share.

If the names are self-verifying, as with secure hashes, you 
don't have to make a trust/no-trust decision about caches,
at least not at the outset. You can make the trust/no-trust
decision on what they give you. Transgressors are always
caught.

> > 2 Self-Verifying URNs
> > 
> > While any kind of URN can be used within the Content-Addressable
> > Web, there is a specific type of URN called a "Self-Verifying
> > URN" that is particularly useful. These URNs have the
> > property that the URN itself can be used to verify that
> > the content has been received intact. It is RECOMMENDED
> > that applications use cryptographically strong self-verifying
> > URNs because hosts in ad hoc CDNs and the Transient Web
> > are assumed to be untrusted. For instance, one could hash
> > the content using the SHA-1 algorithm, and encode it using
> > Base32 to produce the following URN:
> > 
> > urn:sha1:RMUVHIRSGUU3VU7FJWRAKW3YWG2S2RFB
> 
> That's an invalid URN, AFAIK.  There's no authority.  All URIs
> need an authority to vouch for the identity.

URNs need not have authorities -- especially those which are
strictly a function of the content they describe.

(Now, it is true that the URN namespace "sha1" has not yet been
formally documented and reserved in accordance with RFC-specified
procedures, but the above *could* be a valid URN.)

> Also, including a hash of the content in a URI is an extremely
> brittle way of identifying things, unless it is known that
> the content will be static for all time and space.  If that URN
> identified a song in MP3 format, for example, then you'd need
> a new URN to identify the same song in a different format.
> Is that what you want?

For many applications, yes. For stitching together pieces of a
single exact file from dozens of independent sources, absolutely!

You don't want a "mostly acceptable" MP3 to have the same 
reliable name as the "official" or "consensus 'best'" version.

> > It is believed that N2R, N2L, and N2Ls will be the most useful
> > services for the Content-Addressable Web, so we will cover
> > examples of those explicitly. The rest of the N2* headers
> > should be implemented using the conventions used for N2R,
> > N2L, and N2Ls.
> 
> The N2* conventions run completely against the architecture of the Web.
> URIs are resource identifiers.  URNs are one kind of URI.  How many
> URIs does a resource need?

I'd say you want one (a hash-based URN) to serve as the resource's
unfalsifiable "true name". You might want several others (traditionally,
URLs) to reflect the resource's current reachable locations, or 
its names within alternate delivery systems. 

- Gojomo
____________________
Gordon Mohr, gojomo@
bitzi.com, Bitzi CTO
_ http://bitzi.com _






More information about the P2p-hackers mailing list