Re: [GNUnet-developers] Re: URI suggestion

[Igor Wronsky]

On Sun, 21 Sep 2003, Christian Grothoff wrote:

> I agree.  Maybe we should start a discussion WWW-page just like the one that
> we had for namespaces & directories to explore the possibilities?
> I'm not quite sure where we're heading with the URIs, that is where they
> should be used and where not.  For example, I think that gnunet-insert and
> gnunet-download are distinct is a good idea, so mangling URLs for these two
> tools in one format may not really be the best idea (fruit salat).

Well, I didn't like the idea of 'commands' in the URIs in the
first place. ;) [== i.e. search,download,delete and so on].

My practical yet unimaginative stance is the following:

We need a copy-pasteable standard reference to dl any inserted file.
We need a copy-pasteable standard reference to reach a namespace.

These would IMO be the primary uses for GNUnet URIs at the
moment (and near future). I've argued for this philosophy
in some previous message on the list, but for the sake
of completeness, its because of the *awesome* popularity
boost that certain out-of-band link sites have given to
p2p networks like edonkey and bittorrent. We should
have similar option available for third parties that
might become interested in GNUnet in the future.

Another thing that would be of practical value would
be the possibility to address a namespace by just a
human-readable pseudonym. I couldn't come up with a
neat crypto trick for that yet, but atleast it should
be kludgable.

The neatest answer on the market to the 'separate
programs problem' is yet another client: the dl daemon
that todo mentions. This daemon could be used to list
and manage downloads, insertions and searches, and
it would run in the background, and it could be only
contacted through another app, like telnet, web browser
or a custom gui. And it might even be monitoring
a local pipe for commands, so that a very small
app in the middle would be sufficient to e.g. add a
gnunet link found by a web browser to the current
dl list... Depending on the used interface, the daemon
would look like a shell with custom commands
(such as search, view search #x, dl file, etc),
or a web interface, or almost just like gnunet-gtk
if contacted by a gtk client. If this doesn't make
the intuition clear, one should download mldonkey
and see what such a daemon looks like.

The good thing is that coding such a daemon would
be very easy, requiring virtually no or very little
knowledge of gnunet internals and absolutely no
research-grade problems to solve. But as always,
we're probably short on volunteers. ;)


Igor