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. Re: KHK Metadata Proposal (Brandon)
2. Re: KHK Metadata Proposal (Brandon)
3. Re: KHK Metadata Proposal (Benjamin Coates)
4. Re: KHK Metadata Proposal (Benjamin Coates)
5. Re: Re: KHK Metadata Proposal (Brandon)
6. Re: KHK Metadata Proposal (Alexander Barnell)
7. Re: KHK Metadata Proposal (Alexander Barnell)
8. Re: Re: KHK Metadata Proposal (Alexander Barnell)
9. Hello all, here is my (minor) contribution.. :) (Fredrik Hubinette)
10. [Fwd: Code Changelog question] (rob at lists.sourceforge.net)
11. Re: KHK Metadata Proposal (Scott G. Miller)
12. Re: KHK Metadata Proposal (Scott G. Miller)
13. Re: KHK Metadata Proposal (Scott G. Miller)
14. Re: KHK Metadata Proposal (Scott G. Miller)
15. Re: Re: KHK Metadata Proposal (Scott G. Miller)
16. Re: KHK Metadata Proposal (Scott G. Miller)
17. Re: KHK Metadata Proposal (Joseph Solbrig)
18. Re: [Fwd: Code Changelog question] (Adam Langley)
--__--__--
Message: 1
Date: Wed, 21 Jun 2000 15:56:12 -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
> 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 ;)
No, the KHK isn't stored in Freenet. The metadata is stored under the
KHK. The SVK or CHK is stored in the metadata. And metadata isn't
encrypted currently. So yeah, you can't encrypt by KHK. But you can still
encrypt by CHK or SVK so nothing is really lost.
> > 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.
Metadata is dropped like normal data based on the number of hits it
gets. I'm somewhat concerned about the number of naive hits that might
results from searches. Which is why server-side signature validation would
be good. A metadata unrequest mechanism would also work.
--__--__--
Message: 2
Date: Wed, 21 Jun 2000 16:01:25 -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
> 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.
Do you mean the search results should be SVKs/CHKs to the metadata or that
the metadata should contain a SVK/CHK to the data?
I think all data should be referenced by CHK/SVK and the metadata should
contain such references. I don't see any advantage to indexing metadata by
SVKs/CHKs.
> 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.
Quite right.
--__--__--
Message: 3
To: freenet-dev at lists.sourceforge.net
Date: Wed, 21 Jun 2000 15:21:48 -0700
Subject: Re: [Freenet-dev] KHK Metadata Proposal
From: Benjamin Coates <coatesforh...@juno.com>
Reply-To: freenet-dev at lists.sourceforge.net
From: "Scott G. Miller" <scgmi...@indiana.edu>
> 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.
Why not have the search system return URL's? Then it could point to
anything the author wanted it to: KHK, CHK, SVK, ftp, whatever.
--
Benjamin Coates
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
--__--__--
Message: 4
To: freenet-dev at lists.sourceforge.net
Date: Wed, 21 Jun 2000 15:14:09 -0700
From: Benjamin Coates <coatesforh...@juno.com>
Subject: [Freenet-dev] Re: KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
From: Brandon <bl...@uts.cc.utexas.edu>
> 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.
Why would I want to look up a piece of metadata more than once? If I
want the document again, I can just request it directly, right?
If metadata is found by searching, why does it need a human-readable key
at all? Would a user ever want to request metadata directly? (why?)
How does the searching itself work?
> Therefore, there should be an option to sign metadata and to search
> based on (among other criteria), who has signed the metadata.
Why even bother with unsigned metadata? It doesn't appear to have any
great use (if signed metadata were available), and it would be a simpler
protocol and easier to code if there was only one kind instead of two.
> 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.
My unfounded opinion is that it would be best for the servers to return
only metadata that claimed to be signed by the desired person, then have
the client actually check the signature and junk anything that didn't
validate (rare). You could even have the client "complain" about faulty
signatures and have the server check up on it and delete the fraudulent
metadata (at the server's option). There wouldn't be any reason to forge
a signature since it would always be verified, so not much bandwidth
would get wasted.
--
Benjamin Coates
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
--__--__--
Message: 5
Date: Wed, 21 Jun 2000 17:38:13 -0500 (CDT)
From: Brandon <bl...@uts.cc.utexas.edu>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Re: KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
> Why would I want to look up a piece of metadata more than once? If I
> want the document again, I can just request it directly, right?
>
> If metadata is found by searching, why does it need a human-readable key
> at all? Would a user ever want to request metadata directly? (why?)
You are quite rights. A human-readable key is good for two reasons, it's
easy to remember and it's easy to transmit to other people. I have to have
a bookmark in order to easily get to
http://slashdot.org/article.pl?sid=00/06/07/0153238,
but I can easily sit down at any web browser, without my bookmarks, and go
straight to slashdot.org because I can remember it. And I can tell my
friends, hey check out slashdot.org and they can remember it from a
conversation we had.
> How does the searching itself work?
We're not sure yet. A proposal is coming real soon now.
> Why even bother with unsigned metadata? It doesn't appear to have any
> great use (if signed metadata were available), and it would be a simpler
> protocol and easier to code if there was only one kind instead of two.
Some people might not want to sign metadata. You could generate a new
random key to sign it with and that would be about the same as not signing
it. But it would actually be easier to code with optional metadata. I
don't like to generate random values when you could just make the field
optional and give no value.
> My unfounded opinion is that it would be best for the servers to return
> only metadata that claimed to be signed by the desired person, then have
> the client actually check the signature and junk anything that didn't
> validate (rare).
That would be fine. It's just a question of is the save in bandwidth great
enough to justify the increased CPU usage from having servers check
signatures. I think so, but it's open to debate.
--__--__--
Message: 6
From: Alexander Barnell <ae...@doc.ic.ac.uk>
Subject: Re: [Freenet-dev] KHK Metadata Proposal
To: freenet-dev at lists.sourceforge.net
Date: Wed, 21 Jun 100 23:54:44 +0100 (BST)
Reply-To: freenet-dev at lists.sourceforge.net
>
> > > 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.
>
> Metadata is dropped like normal data based on the number of hits it
> gets. I'm somewhat concerned about the number of naive hits that might
> results from searches. Which is why server-side signature validation would
> be good. A metadata unrequest mechanism would also work.
>
There's no point in having automatic serverside authentication of Metadata, it
would harm efficiency.
A better way is to let the client take most of the work. There are two ways
in which this is possible:
1. Clients will verify any signed Metadata. Any metadata found to be
invalid will immediatly be unrequested (the Metadata dropping back to it's
original position in all the node's caching metadatastores).
A more advanced technique would be for a message to be sent back to the
nodes to the effect "hey guys, this metadata is bogus: delete it please".
Any nodes detected as trying to elliminate valid data can be added to
the ignore list of nodes, to prevent further communicaition with them.
2. I envisage a web-of-trust Metadata search, where the client software
will sort search results based upon not only how well the Metadata matches
the request in fuzzy-string/substring/whatever terms, but also how much
trust the user has in the authors of the Metadata.
Updating will be required, so users can keep an up-to-date version of their
trust file, where they give a score between -1.0 and 1.0 for trust for
nyms (-1 is complete dis-trust, 1 is complete trust). Client software can
automatically generate such files by asking users "Was this what you
wanted" for any downloaded and viewed files. The details of the transitive
trust calculations are unimportant - it is possible in many ways.
Anyway, back to the point: Any metadata being returned that is not trusted
by the user can be immediatly unrequested, although still displayed to the
user. This gives the user the opportunity to trust previously untrusted
authors, whilst gradually elliminating metadata that never gets trusted
(spam, for example!) If a user trusts a just-unrequested piece of Metadata,
the metadata can be re-requested to elliminate the effect of the unrequest.
I believe these two methods will be effective in elliminating the obvious
threat of spam in any searching mechanism. Censorship of 'valid' data
by majority is something to consider in more detail.
--__--__--
Message: 7
From: Alexander Barnell <ae...@doc.ic.ac.uk>
Subject: Re: [Freenet-dev] KHK Metadata Proposal
To: freenet-dev at lists.sourceforge.net
Date: Thu, 22 Jun 100 00:03:59 +0100 (BST)
Reply-To: freenet-dev at lists.sourceforge.net
>
>
> From: "Scott G. Miller" <scgmille at indiana.edu>
>
> > 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.
>
> Why not have the search system return URL's? Then it could point to
> anything the author wanted it to: KHK, CHK, SVK, ftp, whatever.
We can accomplish this by splitting Metadata into two sections:
1. The 'searchable' metadata
e.g
Author = Kevin Keegan
Title = White men can't pass
Keywords = Euro2000 Romania Neville Penalty
2. The 'reference' metadata
e.g
PublicKey=Twofish/234596827356...
Signature=234052acdg...
URL=free:CHK-9abcf0982354
URL=http://www.kevin-keegan.cant.manage.co.uk
URL=ftp://ftp.kevin.com
or perhaps more than two sections, if there is good reason to.
I wont describe how such data will be routed etc. because I need
a simulator to back up my ideas first ;)
--__--__--
Message: 8
From: Alexander Barnell <ae...@doc.ic.ac.uk>
Subject: Re: [Freenet-dev] Re: KHK Metadata Proposal
To: freenet-dev at lists.sourceforge.net
Date: Thu, 22 Jun 100 00:06:58 +0100 (BST)
Reply-To: freenet-dev at lists.sourceforge.net
> > Why even bother with unsigned metadata? It doesn't appear to have any
> > great use (if signed metadata were available), and it would be a simpler
> > protocol and easier to code if there was only one kind instead of two.
>
> Some people might not want to sign metadata. You could generate a new
> random key to sign it with and that would be about the same as not signing
> it. But it would actually be easier to code with optional metadata. I
> don't like to generate random values when you could just make the field
> optional and give no value.
>
We dont need updatable-metadata, right? I can't think of any reason why
someone would want to change metadata, unless perhaps they mis-typed
something, or thought of a new keyword to include afterwards. In these
cases they can just create new Metadata, but that leaves us with unwanted
metadata floating round the system..
--__--__--
Message: 9
Date: Wed, 21 Jun 2000 17:36:02 -0700
From: Fredrik Hubinette <hu...@hubbe.net>
To: freenet-dev at lists.sourceforge.net
Subject: [Freenet-dev] Hello all, here is my (minor) contribution.. :)
Reply-To: freenet-dev at lists.sourceforge.net
Last week I thought:
It would be really cool with a distributed peer-to-peer network for
distributing files, all the bandwidth and disk storage one could ever
need. Two days later I find Freenet through a post on slashdot! :)
Anyways, I'd just thought I'd drop a note and say how cool I think this
project is. I'm going to setup a freenet nodes as soon as I find a working
Java for Linux.. :(
I also have something for the contrib page... I've added support for freenet
downloads in my program 'PCP' (Pike CP). PCP can be found on:
http://www.pike-community.org/code/show_single.html?id=2
Insertion support will follow shortly.. :)
On a side note: it would be very nice it was possible to select a range
of bytes to receive, maybe it is already possible? I haven't read the
source yet... :)
/Fredrik "Hubbe" Hubinette
[ shameless plugs: http://fredrik.hubbe.net , http://pike.idonex.se ]
--__--__--
Message: 10
From: euro...@home.com
Date: Wed, 21 Jun 2000 18:41:24 -0700
To: "freenet-dev at lists.sourceforge.net" <freenet-dev at
lists.sourceforge.net>
Subject: [Freenet-dev] [Fwd: Code Changelog question]
Reply-To: freenet-dev at lists.sourceforge.net
Originally sent this to the chat list and it apparently got lost in the
fuddle of morals, god, etc:
Why does the changelog not list current changes, e.g. the latest
snapshots? Is it only major changes or revisions that are added to that
list? Thanks, Rob.
--__--__--
Message: 11
Date: Wed, 21 Jun 2000 21:30:03 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--OgqxwSJOaUobr8KG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> Do you mean the search results should be SVKs/CHKs to the metadata or that
> the metadata should contain a SVK/CHK to the data?
The latter.
>=20
> I think all data should be referenced by CHK/SVK and the metadata should
> contain such references. I don't see any advantage to indexing metadata by
> SVKs/CHKs.
Neither do I. But returning a list of KHKs is bad too, because that means
the server had to have been storing those as plain text. Or the search
mechanism has to allow for a secret known only by the searcher that
encrypts all the metadata. And I can't think of a manner in which this
would work. Unless your using Alex's same-cardinality search method, in
which case they could be encrypted by the plaintext search terms (in
sorted order).
--OgqxwSJOaUobr8KG
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
iD8DBQE5UXorpXyM95IyRhURAjkIAKC2gR9hw88P+A3/R64+tDbR4rKaFgCfSIFV
4JmXDLfBSJVOpgQCYmDYizI=
=LVNR
-----END PGP SIGNATURE-----
--OgqxwSJOaUobr8KG--
--__--__--
Message: 12
Date: Wed, 21 Jun 2000 21:31:39 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="jho1yZJdad60DJr+"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--jho1yZJdad60DJr+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> No, the KHK isn't stored in Freenet. The metadata is stored under the
> KHK. The SVK or CHK is stored in the metadata. And metadata isn't
> encrypted currently. So yeah, you can't encrypt by KHK. But you can still
> encrypt by CHK or SVK so nothing is really lost.
Encryption isn't really the issue. One of the reasons I like the
same-cardinality method is that it allows metadata to be encrypted too,
under the search terms. =20
> Metadata is dropped like normal data based on the number of hits it
> gets. I'm somewhat concerned about the number of naive hits that might
> results from searches. Which is why server-side signature validation would
> be good. A metadata unrequest mechanism would also work.
Also, one might give less credibility to a metadata hit than a data hit.
--jho1yZJdad60DJr+
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
iD4DBQE5UXqLpXyM95IyRhURAiBMAJdMvVLxa8Oy49B1QF9n8q9YoXv1AKC5avDW
BAedBFm4Tci8BY6z+c3+Lw==
=o0Lm
-----END PGP SIGNATURE-----
--jho1yZJdad60DJr+--
--__--__--
Message: 13
Date: Wed, 21 Jun 2000 21:34:08 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--mojUlQ0s9EVzWg2t
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> We can accomplish this by splitting Metadata into two sections:
>=20
> 1. The 'searchable' metadata
>=20
> e.g
> Author =3D Kevin Keegan
> Title =3D White men can't pass
> Keywords =3D Euro2000 Romania Neville Penalty
>=20
> 2. The 'reference' metadata
>=20
> e.g
> PublicKey=3DTwofish/234596827356...
> Signature=3D234052acdg...
> URL=3Dfree:CHK-9abcf0982354
> URL=3Dhttp://www.kevin-keegan.cant.manage.co.uk
> URL=3Dftp://ftp.kevin.com
>=20
> or perhaps more than two sections, if there is good reason to.
>=20
> I wont describe how such data will be routed etc. because I need
> a simulator to back up my ideas first ;)=20
No need to keep them in seperate documents. If the entire thing is
encrypted, both metadata sections can be together. I don't mind the idea
of marking searchable and unsearchable metadata, either.
--mojUlQ0s9EVzWg2t
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
iD8DBQE5UXsgpXyM95IyRhURAs3pAKCDeKCTtjtZH9bVEw54BxMp/5PVHgCeNh5r
w7LEHFAjkPD7rz7hEcY2R4k=
=tlBE
-----END PGP SIGNATURE-----
--mojUlQ0s9EVzWg2t--
--__--__--
Message: 14
Date: Wed, 21 Jun 2000 21:32:45 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> Why not have the search system return URL's? Then it could point to
> anything the author wanted it to: KHK, CHK, SVK, ftp, whatever.
I have no argument against this. I'd still like them encrypted in some
manner though.
--RnlQjJ0d97Da+TV1
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
iD8DBQE5UXrNpXyM95IyRhURAk7vAKCwTBIlpgBAy/DzDrIJ1CTdSJRmegCgnAU/
avPPNRNWCMMlkX1FrMo385c=
=4R60
-----END PGP SIGNATURE-----
--RnlQjJ0d97Da+TV1--
--__--__--
Message: 15
Date: Wed, 21 Jun 2000 21:35:47 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Re: KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="eHhjakXzOLJAF9wJ"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--eHhjakXzOLJAF9wJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> Why even bother with unsigned metadata? It doesn't appear to have any
> great use (if signed metadata were available), and it would be a simpler
> protocol and easier to code if there was only one kind instead of two.
Because if you have to sign it, you lose anonymity. Freenet should cater
to both parties.
--eHhjakXzOLJAF9wJ
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
iD8DBQE5UXuDpXyM95IyRhURAur7AJ99tJyQcR8htRux+n4s4u9UnX01igCbBZSe
H/3hDcUcPMZc/ScEdvjy900=
=MHYS
-----END PGP SIGNATURE-----
--eHhjakXzOLJAF9wJ--
--__--__--
Message: 16
Date: Wed, 21 Jun 2000 21:40:00 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="+KJYzRxRHjYqLGl5"
From: "Scott G. Miller" <scgmi...@indiana.edu>
Reply-To: freenet-dev at lists.sourceforge.net
--+KJYzRxRHjYqLGl5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> A more advanced technique would be for a message to be sent back to the
> nodes to the effect "hey guys, this metadata is bogus: delete it please".
> Any nodes detected as trying to elliminate valid data can be added to
> the ignore list of nodes, to prevent further communicaition with them.
No, this opens up attacks that try to actively remove data.
> 2. I envisage a web-of-trust Metadata search, where the client software
> will sort search results based upon not only how well the Metadata matches
> the request in fuzzy-string/substring/whatever terms, but also how much
> trust the user has in the authors of the Metadata.=20
Thats a client issue, but its certainly possible. I think this is the
place for fuzzy logic (Ian).
> Anyway, back to the point: Any metadata being returned that is not trusted
> by the user can be immediatly unrequested, although still displayed to the
> user. This gives the user the opportunity to trust previously untrusted
> authors, whilst gradually elliminating metadata that never gets trusted
> (spam, for example!) If a user trusts a just-unrequested piece of Metadat=
a,
> the metadata can be re-requested to elliminate the effect of the unreques=
t.
=20
<Mr Mackey>Unrequests are bad.</Mr Mackey>
See above.
> I believe these two methods will be effective in elliminating the obvious
> threat of spam in any searching mechanism. Censorship of 'valid' data
> by majority is something to consider in more detail.
Censorship period is what Freenet is trying to avoid. Remember that in
all cases of revolution in history, the revolutionaries are often the
minorities. Letting the majority have all the power defeats the
purpose.
--+KJYzRxRHjYqLGl5
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
iD8DBQE5UXx/pXyM95IyRhURAmx0AKDOQYA3zXernaYzKb1G5TW4Ae/KcACgnSYJ
YsQX6bdv8GmkZJQe+SPZh98=
=AViR
-----END PGP SIGNATURE-----
--+KJYzRxRHjYqLGl5--
--__--__--
Message: 17
Date: Wed, 21 Jun 2000 23:33:13 -0700
To: freenet-dev at lists.sourceforge.net
From: Joseph Solbrig <jsolb...@webcom.com>
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
At 09:40 PM 6/21/2000 -0500, you wrote:
>
>> I believe these two methods will be effective in elliminating the obvious
>> threat of spam in any searching mechanism. Censorship of 'valid' data
>> by majority is something to consider in more detail.
>
>Censorship period is what Freenet is trying to avoid. Remember that in
>all cases of revolution in history, the revolutionaries are often the
>minorities. Letting the majority have all the power defeats the
>purpose.
>
Yes,
I think that schema aim to eliminate spam (as opposed to mitigating spam)
is going to be censorship. One person's spam is another person's useful
information. Majority votes mean nothing since then it's the tyrany of the
majority.
End spam schemas are too focused the "search" side collecting data. There
is also the "publish" side of data. You need to leave room for people to do
maneuvers to get people's attention. (I mentioned world-writable
directories - some form, as simple as the present human-created keys,
should be visible to folks).
Sure create as good a search system as you can. But there simply is no AI
and no moderator to determine what should rightfully go in
/truth/awful/microsoft. And that's fine. Relax and learn enjoy a bit of
chaos.
--__--__--
Message: 18
Date: Thu, 22 Jun 2000 13:54:17 +0000
From: Adam Langley <a...@linuxpower.org>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] [Fwd: Code Changelog question]
protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c"
Reply-To: freenet-dev at lists.sourceforge.net
--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 21, 2000 at 06:41:24PM -0700, europax at home.com wrote:
> Originally sent this to the chat list and it apparently got lost in the
> fuddle of morals, god, etc:
>=20
>=20
>=20
> Why does the changelog not list current changes, e.g. the latest
> snapshots? Is it only major changes or revisions that are added to that
> list? Thanks, Rob.
>=20
I guess because people can't be bothered to update it. Look at the CVS logs
and the ChangeLogs in each .java file
AGL
--=20
Never underestimate the power of a small tactical nuclear weapon.
--sm4nu43k4a2Rpi4c
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjlSGogACgkQc/sOPsJbMv2AfgCdHosssi6PfFRSy3Qhtv9L9pSo
QOwAniKiCR6VlUdNX1a3YyY4NH8f+4je
=9RD8
-----END PGP SIGNATURE-----
--sm4nu43k4a2Rpi4c--
--__--__--
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
End of Freenet-dev Digest
