>>>>> Miles Fidelman <[email protected]> writes:
>>>>> Miles Fidelman wrote:
[…]
>> What I mean is that
>> gnunet://fs/sks/TU6GGH9COPQLPQTG919BB0QVEVIO1SF1IRGI7ACBGOHKVPNCGRUQG98H4DTTPDNDVMV83E8SI51GR66AL6S47BLLK4LULR8J1A7T188/ivan
>>
>> requires that you have the gnunet software installed, and generally
>> you are typing that URL into the gnunet software. It's not like
>> there's a gnunet protocol and API that is generally accessible
>> across the net. This is simply a representation of a gnunet DHT
>> key.
> To clarify just a bit more: The "scheme" portion of a typical URI
> implies a communications protocol, usually involving "listeners"
> sitting out on the net somewhere that understand the particular
> protocol.
I believe that in the above you've meant UR*L*'s specifically,
and not URI's in general.
> In the case of most DHT's, access is either via a client program, or
> a call into a software library — details of the protocol used between
> nodes running the DHT are hidden from users.
Such details are virtually always hidden from the users. Does
J. Random User understand GET, Host:, and 404 for instance?
And accessing a URL also requires a particular application (such
as a Web browser), or a library (such as LWP) function call, so
it's hardly different to the URN case.
> So... gnunet:...., or more accurately urn:gnunet:.... might work as a
> URN scheme (a way to name things) but would not be very useful as a
> way to actually access anything.
It's better to say that URN's allow the resources to be named
/irrespective/ of the particular protocol that may be used to
access them. Effectively, the choice of the protocol is up to
the receiver of such a URI (an application), not the provider,
as in the case of the more common URL's. Which, to me, seems
like /the/ difference between URN's and URL's.
> (If I haven't been paying attention, and there is something like a
> "gnunet access protocol," complete with resolvers that sit behind TCP
> or UDP listeners, somebody please correct me!).
Unfortunately, I fail to understand this sentence completely.
There's indeed a “GNUnet protocol” (or a suite of protocols),
and all the nodes necessarily have listeners, etc.
However, as I've noted before, it isn't strictly necessary to
use such a protocol to access a resource named in a GNUnet (or
Freenet, or BitTorrent) way, and indeed there're BitTorrent
implementations that, failing to locate peers for a given
resource, resort to downloading it off one or more HTTP servers.
(There're provisions for that in the software, and in the
magnet:, Metalink, and .torrent formats.)
--
FSF associate member #7257
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
