gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] URI format


From: Christian Grothoff
Subject: Re: [GNUnet-developers] URI format
Date: Fri, 6 Aug 2004 18:42:38 +0530
User-agent: KMail/1.5

On Monday 02 Aug 2004 11:30 pm, icepick wrote:
> Hi,
>
> I found out about your new release on freshmeat today.  What drew me in
> was a mention about shorter URI support. I love URI's.  Ask my
> coworkers, I use them as nouns in all my IM (it's not "bug #1777", it's
> "http://bugs.mycompany.com/1777";).  It one of the key features I've been
> adding to Mnet 0.7.
>
> Not having a example of a URI on your front page, I went digging in your
>   FAQ and found this:
>
> gnunet://afs/22BC3B01EF16C2814C23D0401D6C54FFD82C5AB2.8998DE34E06F380661B4E
>BC5991D06C90CD69CFA.7A1AC901.3201028

Looks like the FAQ needs to be updated :-).  That's the old format.

> I have a few suggestions about how this could be improved:
>
> 1) use or support standards already created
>
> There are a few ideas running around about how to identify stuff on p2p
> networks.  One of my favorite use the URN format (URN's are a type of
> URI's):
>
> urn:sha1:<SHA1 Sum of file in Base32>
>
> e.g.
>
> urn:sha1:YJPVMW37VNYRPOAEBUIWM5X6ADF6T3NQ
>
> This is nice and short.  Gnutella uses these.  There is a whole catalog
> of stuff you can find at bitzi.com that has a sha1 urn like that.

Right, but SHA1 cannot be used to download files from GNUnet.  GNUnet uses a 
sophisticated content enoding (http://ovmj.org/GNUnet/download/ecrs.ps) which 
allows for better error checking and privacy than what SHA1 can do.

> To support some of the more information that you want there is also the
> Magnet URI spec
> (http://magnet-uri.sourceforge.net/magnet-draft-overview.txt) which is
> very widely used (kazaa uses it).  It doesn't specify a hashing
> algorithm, but allows for many different systems to use the same syntax.
>   This will allow you to embed all the info that you have in your
> current AFS URI scheme.  It also unfortunately uses "&" :(.

I'm aware of the Magnet URI spec, but I could not see any real benefits in it.

> Being able to support the exact same URI types as other applications is
> I think a good goal to work on.  That way users can try GNUnet for
> something (taking advantage of the the potential anonymity), but then be
> able to fallback on older p2p networks if GNUnet doesn't have it.
> Applications should be written to then have the data published into
> GNUnet so that the next person doesn't have to fallback on the older
> non-anonymous networks.

You can only match URI schemes if the data you need to identify the content is 
equivalent.  Once other networks would encode data in the same fashion, they 
would likely end up with compatible URIs.

> if you don't want to make suggestion #1 you should maybe take these
> other ideas under consideration:
>
> 2) Don't use HEX/Base16, use Base32

That's the change that was done for 0.6.3 (but that did not make it to the 
FAQ).

> http://www.faqs.org/rfcs/rfc3548.html outlines hex/base16, base32 and
> base64.  Base64 has chars in it's alphabet that can't be used in URI's
> thus base32 is a good choice (and used in the above sha1 urn scheme)
>
> 3) Don't use the "//" after "gnunet:".  According to the RFC "//" means
> the next bit of the URI is a host name you can look up via DNS.

I read that "//" indicates that a hierarchical namespace with an authority 
(here: afs) follows.  Please cite the RFC (and the specific section, I've 
looked into RFC 2396 and could not find it saying that "//" requires a 
hostname; it merely states that it is a NETWORK URI, and "afs" definitely 
refers to a network).

> an AFS uri would then look like:
>
> gnunet:afs:YJPVMW37VNYRPOAEBUIWM5X6ADF6T3NQ.KQPVMW37VNYRPOAEBUIWM5X6ADF6T3N
>Q.WM5X.300010
>
> Anyway... my $.02...

Appreciated.

C




reply via email to

[Prev in Thread] Current Thread [Next in Thread]