Send Freenet-dev mailing list submissions to
freenet-dev at lists.sourceforge.net
To subscribe or unsubscribe via the web, visit
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
or, via email, send a message with subject or body 'help' to
freenet-dev-request at lists.sourceforge.net
You can reach the person managing the list at
freenet-dev-admin at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Freenet-dev digest..."
Today's Topics:
1. KHK Metadata Proposal (Brandon)
2. Re: KHK Metadata Proposal (JJ Furman)
3. Re: KHK Metadata Proposal (JJ Furman)
4. Re: KHK Metadata Proposal (Brandon)
5. Re: KHK Metadata Proposal (Adam Langley)
6. Re: KHK Metadata Proposal (Scott G. Miller)
--__--__--
Message: 1
Date: Tue, 20 Jun 2000 18:29:30 -0500 (CDT)
From: Brandon <bl...@uts.cc.utexas.edu>
To: freenet-dev at lists.sourceforge.net
Subject: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
This is a new proposal meant to integrate and synthesize all of the sundry
discussion about KHKs.
----------------------------------------
KHK Metadata Proposal
Author: Brandon Wiley
Goal: To make information findable.
Requirements:
1) Allows for human readable keys
2) Does not depend on out-of-band communication
3) Allows for spam control
[I think that it is important to separate discussions of whether or not these
are good requirements from whether or not this is the best proposal which meets
these requirements.]
Historical Context: The filtering proposal was complicated because it had as
one of its requirements that it cannot rely on searching. As much progress as
been done on the theoretical foundations of efficient searching, this
requirement as been dropped. This opens up the possibility for a simpler
proposal which does not have the same negative side effects as the filtering
proposal.
Proposal:
KHKs should index Metadata. The Metadata has a field pointing to the actual
data, which is stored under a CHK, SVK, etc.. KHKs are first-come, first-serve,
indexing single items, as they are historically.
Metadata is found by searching. Once it is found, its human-readable KHK can be
stored or transmitted and future lookups can be done using just the KHK and no
searching is required.
This satisfies requirements 1 and 2, but it is still spammable in that the
Metadata might point to an item completely different from the one that the
Metadata describes.
The network may be filled with many pieces of metadata claiming to point to
one thing while really pointing to another, thus making searches useless.
Therefore, there should be an option to sign metadata and to search based on
(among other criteria), who has signed the metadata.
Commentary:
Validating signatures on metadata and thus filtering the results can be
done either by the server or the client.
The advantage to having it done on the server is that 1) bandwidth will
not be wasted sending results that will later be discarded and 2) signed items
will get more hits than unsigned items, reducing the amount of storage space
taken up by spam.
The advantages to having it be done by the client are that 1) the
server is minimalistic and 2) the server doesn't have to spend resources
processing signatures.
--__--__--
Message: 2
Date: Tue, 20 Jun 2000 18:14:27 -0700
From: JJ Furman <jfur...@excitehome.net>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
Brandon wrote:
> Metadata is found by searching. Once it is found, its human-readable KHK can
> be
> stored or transmitted and future lookups can be done using just the KHK and no
> searching is required.
I must admit I still don't fully understand how searching is going to work. Can
someone explain the current thinking on this? (Might even be nice to outline
opposing views to prevent silly wars from breaking out) Also, can you include
the
problems with the current ideas?
Thanks
--__--__--
Message: 3
Date: Tue, 20 Jun 2000 18:16:05 -0700
From: JJ Furman <jfur...@excitehome.net>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
Brandon wrote:
> Metadata is found by searching. Once it is found, its human-readable KHK can
> be
> stored or transmitted and future lookups can be done using just the KHK and no
> searching is required.
I must admit I still don't fully understand how searching is going to work. Can
someone explain the current thinking on this? (Might even be nice to outline
opposing views to prevent silly wars from breaking out) Also, can you include
the
problems with the current ideas?
Thanks
JJ
--__--__--
Message: 4
Date: Tue, 20 Jun 2000 20:28:32 -0500 (CDT)
From: Brandon <bl...@uts.cc.utexas.edu>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
> I must admit I still don't fully understand how searching is going to work.
> Can
> someone explain the current thinking on this? (Might even be nice to outline
> opposing views to prevent silly wars from breaking out) Also, can you
> include the
> problems with the current ideas?
I can outline *my* current thinking on this. :-) If I try to paraphrase
other people, I'll probably get it wrong.
I'm attempting to do metadata queries (as opposed to keyword or key
substring searches). Alex and I have been discussing it under the thread
Mathematical Reasoning.
I know that's a really lacking description of what's going on, but I'm
really tired. We should have a proposal out in less than a week. I'm just
waiting for Alex to send me some pictures. Well, we'll probably have 2
proposal because he wants to use some kind of pattern-learning,
intelligent caching thing and that's too complicated for me, so we'll
probably have to split into opposing camps. :-)
But Alex and I have come up with 5 possible ways to search, and that's in
addition to Ian's keyword searching and Umea and sundry other ideas people
have mentioned offhandedly. So we don't really know. :-)
Yep, yep, time to write up some proposals. Then we gotta do some
simulatin' and such.
--__--__--
Message: 5
Date: Wed, 21 Jun 2000 16:00:44 +0000
From: Adam Langley <a...@linuxpower.org>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="UHN/qo2QbUvPLonB"
Reply-To: freenet-dev at lists.sourceforge.net
--UHN/qo2QbUvPLonB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 20, 2000 at 06:29:30PM -0500, Brandon wrote:
> Proposal:
> KHKs should index Metadata. The Metadata has a field pointing to the actu=
al
> data, which is stored under a CHK, SVK, etc.. KHKs are first-come, first-=
serve,
> indexing single items, as they are historically.
>=20
> Metadata is found by searching. Once it is found, its human-readable KHK =
can be
> stored or transmitted and future lookups can be done using just the KHK a=
nd no
> searching is required.
So the KHK is stored in the metadata. This stops the idea of encrypting data
with KHK's. But Scott and Oskar aren't around to argue ;)
> Therefore, there should be an option to sign metadata and to search based=
on
> (among other criteria), who has signed the metadata.
I think you will have to have a system
where unwanted mappings (which is pretty much what they are) are dropped
like Freenet does with docuements currently.
AGL
--=20
The Street finds its own uses for technology.
--UHN/qo2QbUvPLonB
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjlQ5qsACgkQc/sOPsJbMv1FpgCgquapI0sOz9hRvmIJD+WPigmF
XzAAnAne7NiUDQ5lNaKTuQhFPViSh2lF
=p7Tx
-----END PGP SIGNATURE-----
--UHN/qo2QbUvPLonB--
--__--__--
Message: 6
Date: Wed, 21 Jun 2000 10:37:48 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> > searching is required.
>=20
> So the KHK is stored in the metadata. This stops the idea of encrypting d=
ata
> with KHK's. But Scott and Oskar aren't around to argue ;)
Yes I am! And you're right. The idea of including plaintext KHKs
anywhere in freenet just blows. I'd rather the searches return just SVKs
and CHKs.
> > Therefore, there should be an option to sign metadata and to search bas=
ed on
> > (among other criteria), who has signed the metadata.
>=20
> I think you will have to have a system
> where unwanted mappings (which is pretty much what they are) are dropped
> like Freenet does with docuements currently.
Actually, from what I understand of his proposal, that does happen. I
would assume when a filter (server side) rejects documents, it just doesnt
count them as requested.
--+QahgC5+KEYLbs62
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5UOFMpXyM95IyRhURAoj6AKCVer/SJUEDvHoqAumk3Uxn2v7GjQCgyq5C
UO8jWE8zX0ZLmllQyybJOjo=
=sD9W
-----END PGP SIGNATURE-----
--+QahgC5+KEYLbs62--
--__--__--
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
End of Freenet-dev Digest
