Oskar Sandberg wrote:

> I believe that what Singal11 was trying to say (quite correctly) is that
> that is not what Freenet is.

Surely Freenet "is" whatever the client writers make it look like. Users
won't appreciate the elegance of the routing mechanisms or the daring
rejection of the old idea of distinct hosts. No. They will only care to
the extent that they can do what they want to - insert files and request
files. Easily, without any particular knowledge of Freenet
peculiarities.

The sourceforge page is quick to throw Freenet in with Gnutella and
Napster, when there really are few similarities.

> Freenet and Napster are completely different. There is no way to hack
> Freenet support into Napster (or vice versa). To start with we don't have
> searching. Secondly everyone would have to start by inserting their entire
> mp3 library.

If you mean Napster as "the protocol for querying a central host as to
the addresses of peers who have file X" then no, Freenet can't emulate
it. But if you care about the mechanism only to the extent that you must
to get your music, then Freenet can satisfy that single criterion: it'll
get music for you.

Surely something could be worked out where, say, competing release
groups update their respective lists of keys by inserting them to their
subspaces under predefined changing guessable keys (i.e.,
kewl_rippers-12.14.00.list). The community would soon focus on a small
number of central key lists, and, for all practical purposes, the lists
of keys would *be* the client. The actual code would be nothing more
than a vanilla client that could request and parse automatically a user
defined set of lists. The user searches for "metallica", the client just
looks it up in the current lists and spews out the possibly very
redundant results.

It can be done many ways.

So yes, what making a "Freenet Napster" would entail (at least as I see
it) is more an issue of community building then code building. But users
will still need an intuitive client to recommend to others - "Yeah, you
just get l33tMP3z 2.0 and type in kewl_group where it says key list!"

> Freenet is not a protocol that allows other people to look through your
> local MP3 collection. Never was, never will be.

Nor is Napster, at least in the eye of the public. To the masses Napster
is a web site you go to that lets you download music through what to
them seems an cryptic and overly complex interface. What they expect, of
course, is a nice user friendly page with a big list of albums and fast,
reliable links to each track. With a Freenet browser plugin this is a
reality.

The question "is this a Napster clone?" is bullshit and semantics. It's
Freenet.

> If you want to compare Freenet to something - compare it to the WWW.

The sourceforge page does this in the abstract.

> Not to diss your work, but a bunch of new clients are not badly needed at
> this point.

Right now we could use a freenet/key mime type (kinda like shoutcast
.pls files) and a simple cross platform client to handle them. The files
linked would be simple lists of redundant keys. For example, I could add
to my page <a href="ratm-testify.free">RATM - Testify</a>. The file
referenced would consist one or more freenet keys that point to that
particular song. Optionally an "and/or" syntax could be used, so one
link could reference many tracks, each possibly with multiple keys.
Maybe the "and" is too open to abuse. Probably. OK, scrap the and.

IMHO this is very worthwhile. I'll write something in C today. It'll pop
up a little netscape-esque download box and compute throughput.

> And if the only thing keeping out developers is most C coders dogmatic
> approach to Java, how come Adam doesn't have a hundred developers helping
> him with Whiterose?

Anyone man enough to volunteer? ;)

-- 
Mark Roberts
mroberts100 at mediaone.net
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to