I just wanted to provide a few clarifications in this discussion, without trying to argue a particular point (as I'm sure I'm enough of an expert on URNs to have a definitive opinion).
On 10/19/2012 09:18 PM, Miles Fidelman wrote: > GNUnet has one protocol for node-to-node communication, which has a lot > to do with how key-value pairs are distributed across nodes in the > distributed hash table. I'm not sure what your point here was, but just to clarify: GNUnet has more than one protocol. You can run GNUnet peers that do not even run any DHT code. You can do file-sharing without using the DHT at all as the DHT is used for non-anonymous file-sharing (and other applications) whereas GAP-routing is used for anonymous file-sharing. Yet other applications in the system use neither GAP nor the DHT. > What GNUnet DOESN't have (I don't think) is a well-defined interface for > simply getting/putting stuff from/to a hash table. Without that, the > notion of a URI scheme doesn't make a lot of sense. That is not quite true. gnunet-dht-put and gnunet-dht-get are command-line interfaces for accessing the DHT and gnunet_dht_service.h contains a C API implemented by libgnunetdht. Then there is a Java class org.gnunet.dht.DistributedHashTable that provides a (largely equivalent) Java API. Finally, 'dht.h' specifies the structs of an IPC protocol (over TCP or UNIX domain sockets) to access the DHT. So the correct statement would be that GNUnet has *four* interfaces for getting/putting stuff from/to the DHT. We can argue about them being "well-defined" --- they didn't go through the RFC-process, so maybe that means this does not qualify ;-). Now, the DHT does not store the data blocks for files that you might download via gnunet://fs/chk/-downloads, so I'm again not sure how this relates to the URI/URL discussion. On 10/19/2012 04:30 PM, Ivan Shmakov wrote: >>>>>> Stephane Bortzmeyer <[email protected]> writes: > >> Many URI schemes include a hierarchical element for a naming > >> authority so that governance of the name space defined by the > >> remainder of the URI is delegated to that authority (which may, in > >> turn, delegate it further). > > Arguably, there's neither such delegation, nor such governance, > in the case of GNUnet. Instead, each and every GNUnet > implementation simply /knows/ what the gnunet://fs/ URI's are, > and what to do with them. > > It simply doesn't seem quite right to me to use an “authority” > for a content-derived identifier. That may be a matter of taste > (as, indeed, the specification doesn't require that a DNS name > is used for “authority”), but still, it doesn't fit the by now > well-established pattern URN's at large adhere to. > > I still suggest replacing //authority/ with namespace: before > GNUnet URI's are submitted for IANA registration. (Should such > a registration become imminent, or prior to that.) You might want to look at the implementation of gnunet-uri before claiming that there is no delegation to an authority within the gnunet://-subspace: https://gnunet.org/svn/gnunet/src/util/gnunet-uri.c gnunet-uri actually knows nothing about "fs" (or gads or other gnunet-sub-authorities). gnunet-uri only looks at a configuration file which provides a mapping from the sub-part ("fs" in the example) to a binary that it is supposed to invoke (i.e gnunet-fs-gtk). Note that gnunet-fs-gtk may not be installed, in which case the lookup fails and gnunet-uri also fails (as it doesn't understand *fs*.). So saying that each and every GNUnte installation simply /knows/ is simply false: if you didn't install the (separate download) gnunet-gtk.tar.gz, your gnunet-uri will NOT handle gnunet://fs/-URIs. Another authority we delegate to is the "gns" subsystem, for URIs of the form gnunet://gns/HASH/name. This delegation is these days enabled by default via the config lines: [uri] gns = gnunet-namestore which say that the authority for 'gns' is the 'gnunet-namestore' command-line tool. So I believe we are in the scenario Stephane described: we include a hierarchical naming element to delegate authority. Final little note: we've started to document and try to install URI handlers so that if a browser encounters a gnunet://-URI, it can be easily configured to invoke gnunet-uri and thus trigger the correct, protocol-specific action. The limit here is that obviously each OS needs to do URI-scheme registration differently and doing this right is non-trivial --- our goal is certainly for everyone to support gnunet://-URIs everywhere ;-). Happy hacking! Christian _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
