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

Mark Baker distobj at acm.org
Thu Oct 25 14:28:01 UTC 2001


Hi Gordon,

> > 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.

s/theory/spiteful rumour/g 8-)

> However, the latest W3C "clarification"
> seems to simply confirm the practice of using some URIs as if
> they were URNs.

Even HTTP URIs.

Yes, that debate still exists.  In general, REST proponents
believe that any URI is only as persistent as the authority is
willing to make it.  The dependance of the HTTP URI scheme on
DNS, and that an authority doesn't "own" it, is often mentioned
as a reason why HTTP URIs are less persistent.  But that ignores
the fact that for urn:<nid>:foo, the registrant doesn't own
"nid" either.  If IBM runs out to register "microsoft" as a NID,
you can guarantee WIPO will eventually get involved.  It's just
another central registry.

> 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.

I have an issue with the name "self-verifying".

If I do a GET on urn:sha-1:234234KJASDFKAJFD, I don't know that
I'm getting back a resource with that hash.  I still have to
run the hash and compare it to the URI, because the cache may
be lying.  So the honus of verification lies with the client,
and therefore the URI isn't self-verifying.

But if it's still really important for this system to have the
hash in the URI, how about this;

http://foobar.org/my_content?sha1hash=32452345ASDASDFASDFS

> > 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!

Ok, so how about my URI above?

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

HTTP handles that with variants (different representations of the
same resource).  Variants can have their own URIs too.  So you
could have;

http://myfavband.org/song/myfavsong (the main URI)

plus these variants;

http://myfavband.org/song/myfavsong/mp3/256k
http://myfavband.org/song/myfavsong/mp3/128k
http://myfavband.org/song/myfavsong/wav/56k
http://myfavband.org/song/myfavsong/au/8k

> 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. 

Do you have an example of a resource that is best named by its
hash?

MB
-- 
Mark Baker, CSO, Planetfred.
Ottawa, Ontario, CANADA.
mbaker at planetfred.com



More information about the P2p-hackers mailing list