-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Je jxauxdo 19 Aprilo 2001 14:43, vi skribis:
> It's actually quite simple, certainly more simple than what you proposed.
> And it's totally client-side and already coded, so it's certainly
> more easy to implement. Here's how you insert a key, from a user's
> perspective:
How is it more simple? I mean, infrastructure-wise? The instructions page
for using the key catalog is over three pages, printed... granted, half of
that was a discourse on proper key construction, but I still think that it
should be easier than that to insert data.
Programmatically, given a decent hash function, I could whip out a Java
implementation of a system like the one I described pretty quickly, although
binding it into Freenet will involve a learning curve on my part.
An insert by a user would look something like:
Insert_Into_Freenet \
-file Calculator.jar \
-key "rpn / calculator / java / program / desktop utility"
The keys would be split by '/' then whitespace trimmed, hashed, and stored in
whatever key-file hashtable is being used.
I'm sorry, but this just seems a heck of a lot more easy than forcing users
to construct some cryptic key like "freenet:KSK@test-key" -- however, key
construction is another topic altogether.
> You can also do KeyIndexClient -list keyindex to get a list of keys from
> an index.
This is one advantage to catalogs that just can't be done with the hashed key
mechanism. In fact, the inability to be able to identify content by its key
(possible with reverse-lookup with any catalog system) makes hashed keys to
be more "safe" than catalogs.
> You still don't understand the mechanism. There is no key server. It's
> just a bunch of files in Freenet. The "keyindex" parameter is just a name
- From http://freenetproject.org/in-freenet-keyindex.html :
"The first thing you have to do is find an Index that you can send your key
to. Obviously, this is a chicken-and-egg problem. As of this writing, there's
not any good in-Freenet key indices, so there's not much help from this
front."
It can't be both ways: either the index resides in one place, or you end up
with static indexes. If you have multiple copies of the index floating
around, you can't guarantee that all of the copies of an index are going to
receive new insert requests, so you're going to get out-of-sync indexes. Not
to mention the fact that you're consuming extra storage just to support your
lookup mechanism. On the other hand, if you have one server managing the
catalog, you solve the static-catalog problem but you have a single point of
failure.
> you make up. For instance, "sites" is a good name for an index which
> contains keys pointing to freesites. And "steve" is a good name for an
> index which you submit things to if you want them to show up on Steve's
> Key Index.
So indexes are files in the system, which the system treats differently from
regular files, and hopefully people will psychically know what the meta-keys
of these indexes are. It is starting to look to me like we're going to end
up with the same problem that needed to be solved with catalogs in the first
place... are we going to have a catalog of indexes?
First a user has to get a list of indexes; this is done by fetching an
ueber-index of indexes (they hope that the one they get is the most recent).
Once they have that, they can fetch the index to list the objects which are
in the index, hoping, again, that they've retrieved a reasonably up-to-date
index. Then they send out the request for the file they want. If the file
is within reach, it is returned -- the advantage being that the user is
pretty sure s/he knows what s/he is getting. With the hash system, there is
more uncertainty.
So, given reasonable popularity, a catalog-based system will also generate
significantly more network traffic. Assume that the primary index doesn't
grow to more than a couple of K, the secondary indexes could easily number in
the tens of kilobytes -- the "sex" index alone may eventually make it into
the megabytes.
Again, I'd argue that the hash system is, safer for the data host. A file's
key may match "kiddie porn", but it may also match "kiddie porn as a social
disease", whereas a *given* index description "kiddie porn movie" is a lot
less ambiguous. Still, this is a relatively minor concern.
I still prefer the clean, straightforward design of completely obfuscated
requests going out, and each server the request reaches responds with the
file (or option to download the file). This is once (or twice) out, and once
(or twice) back. With the catalog system, I'm seeing at least three outgoing
requests, and three incoming responses -- and two of those incoming requests
are going to involve orders of magnitude more network traffic.
Maybe it would help if you told me WHY hashed-key searches are worse, or WHY
catalogs are better.
BTW, I'd be MORE than happy to implement the hashed-key search code. Unless
the existing Freenet code is pretty hairy, it shouldn't very long.
=== SER Deutsch|Esperanto|Francaise|Linux|Java|Aikido|Dirigibles|GPG
=== http://www.germane-software.com/~ser jabber.com:ser ICQ:83578737
"One World, one Web, one Program" - Microsoft promotional ad
"Ein Volk, ein Reich, ein Fuhrer" - Adolf Hitler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6328NP0KxygnleI8RAkwQAJ9Cy1fjiHhDYQvFPTn1LIzjixFLUACfR87n
R4AHK+7PilGB+KKJKlc2fiM=
=y357
-----END PGP SIGNATURE-----
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
