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: Meaningless hits on metadata (Brandon)
3. Re: 0.3 Todo List (Brandon)
4. Re: 0.3 Todo List (Brandon)
5. Re: KHK Metadata Proposal (Brandon)
6. Re: 0.3 Todo List (Brandon)
7. Re: Meaningless hits on metadata (Brandon)
8. Re: 0.3 Todo List (Jason Marshall)
9. RE: A Metadata Filtering Proposal (Benjamin Coates)
10. Re: 0.3 Todo List (Brandon)
11. RE: 0.3 Todo List (Benjamin Coates)
12. Re: KHK Metadata Proposal (Scott G. Miller)
13. Re: KHK Metadata Proposal (Scott G. Miller)
14. Re: 0.3 Todo List (Oskar Sandberg)
15. Re: KHK Metadata Proposal (Brandon)
16. Re: KHK Metadata Proposal (Oskar Sandberg)
17. Re: Promoting metadata (was: Meaningless hits) (Daniel Phillips)
18. Re: Promoting metadata (was: Meaningless hits) (hal at finney.org)
--__--__--
Message: 1
Date: Sun, 25 Jun 2000 14:54:54 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
> Could you some up the idea that has been "accepted"?
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.
> Serching is by the far the most difficult problem, and it is not
> going to happen just like that.
Definitely. I'm not considering 0.3 to be something we can get done
quickly. But you're right, it's such a big step that we should probably
come out with a 0.3 release with a GUI and leave searching for 0.4.
The GUI is not included in the release in an easily usable way, meaning
there is no icon to click on which launches it.
> A GUI shell for the node can be coded by everyone. If you are
> reacting to the latest bunch of "I tried clicking on everything but
> it just said bad command", then consider that these people do not
> even have a JRE installed, so getting a GUI will hardly help them
> (unless somebody feelslike writing and installshield type thing that
> dls and installs a JRE).
Even if they had a JRE installed, clicking on fserve.bat wouldn't do what
they're expecting.
> KeyTypes and there first usage for CHKs. Then SVKs (without
> updating), and the more secure SVK-like KHKs.
I don't see why CHKs need to go into the next release. Sure if they're
ready, they should go in as soon as possible, but if they're not ready, I
don't see why we should delay to include them. What we really need to get
out there fast is stuff that makes it easier for newbies to use.
> Searching and updating, the "big two" will have to wait.
You're right, these should be 0.4.
> I had a standing promise from you people that we would not let the
> press attention control us.
It's not for the press, it's for the new users, which are of course caused
by the press. I don't care about the press at all. They simultaneously say
that we're changing the world and that we have pre-alpha hard to use
software. They're totally unreasonable. But there are a lot of people
downloading Freenet and not being able to use it and I think that's
unfortunate.
--__--__--
Message: 2
Date: Sun, 25 Jun 2000 14:56:51 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Reply-To: freenet-dev at lists.sourceforge.net
> I don't see how. Nodes need the plain-text of values to perform fuzzy
> matching (and fuzzy routing). Nodes need the plain-text of fields to allow
> matches to be performed in the case where the request includes just fields
> A and B, but the node has something matching in its store with fields A, B
> and C. If the fields were encrypted, there would be no way of knowing it
> was a match.
If we do either the one insert per field or else the powerset insert then
it's basically just a KHK. You convert the name, field pairs into strings
and then hash. It wouldn't work if we fill in missing fields. I'm not
saying we can encrypt, just that we maybe can encrypt.
--__--__--
Message: 3
Date: Sun, 25 Jun 2000 14:59:50 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] 0.3 Todo List
Reply-To: freenet-dev at lists.sourceforge.net
> - some standard for splitting/interleaving files.
I don't see why this is a feature which we absolutely must push out the
door right away. I think it can wait a while.
--__--__--
Message: 4
Date: Sun, 25 Jun 2000 15:01:44 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] 0.3 Todo List
Reply-To: freenet-dev at lists.sourceforge.net
> This is a great idea, but is it legal to just grab and install the JRE?
> Perhaps if we included a copy of the JRE disclaimer in the install
> program, with Sun's permission.
Hell no. And they won't give us permission. We can send them some money if
we want to do that. Or we can bundle Kaffe, but I'd rather not.
> I agree, and propose that a preliminary-metadata search facility should
> be setup in a similar way to the web-key-informing we have now. This will
> allow us to start developing clients with search facilities, will
> please end-users, all without us committing ourselves to a potential
> flawed search mechanism. When we do implement proper search, the change
> will be transparent to end-users, since the client will look the same.
I'm not sure what you're suggesting. Is this a client or server feature
which you want to add? Or both?
--__--__--
Message: 5
Date: Sun, 25 Jun 2000 15:06:54 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
> > - node to node encryption
> > - file encryption
> Both of these have been done for quite some time.
Right. Sorry, I meant list of features we should have in 0.3, not actually
what we need to do to get 0.3 out.
> > So please add other important 0.3 stuff to this list and I'll try to come
> > up with some sort of organization, put it in the bug/task manager or
> > something.
> I really don't want to put 0.3 out the door until we have CHKs. I'd
> *like* SVKs too, but that implies updating.
Now I don't see what the big rush is for CHKs. I'm all for CHKs. I think
they're very important. But I consider the next release to be a response
to the rapidly growing number of users. Now is a good time to get a big
user base, which we of course want. But most users aren't going to care
whether the underlying mechanism is based on CHKs or not. They just want a
GUI and searching so it can be like Gnutella. I suppose maybe the
difference in thought here is that I'm really thinking of it more like a
0.2.1 release (minor UI improvements) rather than a real 0.3 (major
structural changes). Except that I wanted to add searching, but I agree
that that's unrealistic inside of a reasonable time frame.
--__--__--
Message: 6
Date: Sun, 25 Jun 2000 15:11:31 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] 0.3 Todo List
Reply-To: freenet-dev at lists.sourceforge.net
> You're right. We need to start specifying the format of these documents
> that are supposed to specify things like CHK redirects, SVK version
> stacks, and multipart files.
I was thinking we could implement this with message subclassing. So
Reply, DataReply, DataReplyMultipart, and so on. As opposed to adding
another field. That way you could add the ability to handle new document
types by installing a plugin class to handle the message subclass.
--__--__--
Message: 7
Date: Sun, 25 Jun 2000 15:14:01 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Reply-To: freenet-dev at lists.sourceforge.net
> We hash things normally so as to make sure that the routing of
> information does not reflect the content of the
> (descriptive) keys. However, with searching this is the point, so
> hashing makes little or no sense.
If we encrypt the metadata with the search key and hash the search key,
then that would be good. Encrypted metadata would be good because while it
would be a lot less useful to block metadata than data, it would still be
nice if it was hard to do. But only some search solutions allow for
metadata encryption.
--__--__--
Message: 8
From: Jason Marshall <[email protected]>
Subject: Re: [Freenet-dev] 0.3 Todo List
To: freenet-dev at lists.sourceforge.net
Date: Sun, 25 Jun 2000 12:30:47 -0700 (PDT)
Reply-To: jmarsh at serv.net
Reply-To: freenet-dev at lists.sourceforge.net
> > This is a great idea, but is it legal to just grab and install the JRE?
> > Perhaps if we included a copy of the JRE disclaimer in the install
> > program, with Sun's permission.
>
> Hell no. And they won't give us permission. We can send them some money if
> we want to do that. Or we can bundle Kaffe, but I'd rather not.
Pardon? The whole point of the JRE was to have a redistributable version.
>From http://java.sun.com/j2se/1.3/runtime.html:
The Java 2 Runtime Environment is redistributable, unlike the Java 2
SDK.
The Java 2 Runtime Environment License allows you to package it with
your
software. By distributing the Java 2 Runtime Environment with your
application, you can ensure that your customers will have the correct
version of the runtime environment for running your software.
-Jason
--__--__--
Message: 9
Date: Sun, 25 Jun 2000 16:23:22 -0400
From: Benjamin Coates <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: RE: [Freenet-dev] A Metadata Filtering Proposal
Reply-To: freenet-dev at lists.sourceforge.net
> From Alex Barnell <aeb99 at doc.ic.ac.uk>
> But then again, I see your point about negative trust being fairly useless.
A
> compromise could be that we trust someone iff, say, over 90% of the metadata
> they have published has been correct. And this trust would be a yes/no
thing,
> simplifying the maths tremendously (and probably the usefullness of results)
That would be good. The client could be written / configured to use any
system the user wanted to determine trust, and then publish the final
decision.
--
Benjamin Coates
--__--__--
Message: 10
Date: Sun, 25 Jun 2000 15:27:19 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] 0.3 Todo List
Reply-To: freenet-dev at lists.sourceforge.net
> Pardon? The whole point of the JRE was to have a redistributable version.
> >From http://java.sun.com/j2se/1.3/runtime.html:
Sorry, I was completely wrong. :-)
--__--__--
Message: 11
Date: Sun, 25 Jun 2000 16:31:49 -0400
From: Benjamin Coates <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: RE: [Freenet-dev] 0.3 Todo List
Reply-To: freenet-dev at lists.sourceforge.net
>===== Original Message From Alex Barnell <aeb99 at doc.ic.ac.uk> =====
>This is a great idea, but is it legal to just grab and install the JRE?
>Perhaps if we included a copy of the JRE disclaimer in the install
>program, with Sun's permission.
Sun's JRE notes for developers is at
http://java.sun.com/products/jdk/1.2/runtime.html
The JRE license is at http://java.sun.com/products/jdk/1.2/jre/LICENSE
It looks to me like we can just redistribute it, as long as we don't alter
anything.
--
Benjamin Coates
--__--__--
Message: 12
Date: Sun, 25 Jun 2000 15:36:12 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> I don't see why CHKs need to go into the next release. Sure if they're
> ready, they should go in as soon as possible, but if they're not ready, I
> don't see why we should delay to include them. What we really need to get
> out there fast is stuff that makes it easier for newbies to use.
I think you're priorities don't agree with mine. Mine are to create a
complete, secure freenet. A good, quality system. Not to try and rush
out releases that are more and more newbie friendly.
> > I had a standing promise from you people that we would not let the
> > press attention control us.=20
>=20
> It's not for the press, it's for the new users, which are of course caused
> by the press. I don't care about the press at all. They simultaneously say
> that we're changing the world and that we have pre-alpha hard to use
> software. They're totally unreasonable. But there are a lot of people
> downloading Freenet and not being able to use it and I think that's
> unfortunate.
The new users =3D=3D the press. Our job isn't to cater to the new users, b=
ut
to create a product that the new users will like. Build it and they will
come.
--82I3+IH0IqGh5yIs
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
iD8DBQE5Vm08pXyM95IyRhURAoo5AKDJlgK7GaFM9F1nrijRvuZIa8cijACgy7ka
UdnxT7QBS9IOrQ7XdO3ZSnM=
=zC5P
-----END PGP SIGNATURE-----
--82I3+IH0IqGh5yIs--
--__--__--
Message: 13
Date: Sun, 25 Jun 2000 15:37:43 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--R3G7APHDIzY6R/pk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
> Now I don't see what the big rush is for CHKs. I'm all for CHKs. I think
> they're very important. But I consider the next release to be a response
> to the rapidly growing number of users. Now is a good time to get a big
> user base, which we of course want. But most users aren't going to care
> whether the underlying mechanism is based on CHKs or not. They just want a
> GUI and searching so it can be like Gnutella. I suppose maybe the
> difference in thought here is that I'm really thinking of it more like a
> 0.2.1 release (minor UI improvements) rather than a real 0.3 (major
> structural changes). Except that I wanted to add searching, but I agree
> that that's unrealistic inside of a reasonable time frame.
Whats the point of garnering a lot of new users if we're going to break
the network under them often? Not a good idea. People that use Freenet
now should know that they are doing so to help betatest it, not to use a
running system.
--R3G7APHDIzY6R/pk
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
iD8DBQE5Vm2XpXyM95IyRhURAgKwAKCODMKcqWwEFq8GNAY1nsiuNqU5rwCgipn0
QfdL4rejbI5R81dV718p1Cc=
=fjWX
-----END PGP SIGNATURE-----
--R3G7APHDIzY6R/pk--
--__--__--
Message: 14
Date: Sun, 25 Jun 2000 22:44:33 +0200 (MET DST)
From: Oskar Sandberg <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] 0.3 Todo List
Reply-To: freenet-dev at lists.sourceforge.net
This does not effect the messages, it effects only the data. It is
purely a client issue.
Oskar Sandberg
md98-osa at nada.kth.se
On Sun, 25 Jun 2000, Brandon wrote:
>
> > You're right. We need to start specifying the format of these documents
> > that are supposed to specify things like CHK redirects, SVK version
> > stacks, and multipart files.
>
> I was thinking we could implement this with message subclassing. So
> Reply, DataReply, DataReplyMultipart, and so on. As opposed to adding
> another field. That way you could add the ability to handle new document
> types by installing a plugin class to handle the message subclass.
>
>
>
> _______________________________________________
> Freenet-dev mailing list
> Freenet-dev at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/freenet-dev
>
--__--__--
Message: 15
Date: Sun, 25 Jun 2000 15:56:54 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
> I think you're priorities don't agree with mine. Mine are to create a
> complete, secure freenet. A good, quality system. Not to try and rush
> out releases that are more and more newbie friendly.
I don't see these are being contradictory. My goal is to come out with
releases which are more complete, more secure, and more newbie
friendly. Being as how we are about to acquire a lot more newbies, now
seems like a good time for a newbie friendlier release.
> The new users == the press. Our job isn't to cater to the new users, but
> to create a product that the new users will like. Build it and they will
> come.
Not at all. The press aren't users. Putting out a new release for the
press would mean giving it more news-friendly features (new, easier to use
MP3 downloading interface, 10% faster than Gnutella, get your local news,
sports, and weather from Freenet).
I totally agree that our job is to create a product that new users will
like.
--__--__--
Message: 16
Date: Sun, 25 Jun 2000 23:16:22 +0200 (MET DST)
From: Oskar Sandberg <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
On Sun, 25 Jun 2000, Scott G. Miller wrote:
> I think you're priorities don't agree with mine. Mine are to create a
> complete, secure freenet. A good, quality system. Not to try and rush
> out releases that are more and more newbie friendly.
Amen. We have the advantage of not working under the pressure of a
marketing department and adminstration pressing us for
features and deadlines - lets not let the attention we have gained be
that for us. We do this at the rate it comes to us - our only
requirement that we do not compromise the goals of this project.
> The new users == the press. Our job isn't to cater to the new users, but
> to create a product that the new users will like. Build it and they will
> come.
Amen again. None of the really amazing technologies of late have come
in a stream of press reports and interviews, and they have thrived
all the same. In the long run, the only thing that matters is whether
the technology we present is sound or not - if it is, and if there is
a need for it, the users will come.
> >
--__--__--
Message: 17
From: Daniel Phillips <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata (was: Meaningless hits)
Date: Mon, 26 Jun 2000 00:30:14 +0200
Reply-To: freenet-dev at lists.sourceforge.net
On Sun, 25 Jun 2000, Daniel Phillips wrote:
> On Sat, 24 Jun 2000, Brandon wrote:
> > > Some things are just too obvious to see right away. If the user
> > > originates the
> > > data request through the same server as the search (the normal case) then
> > > that
> > > server can easily associate the metadata with the data, and can "touch"
> > > the
> > > metadata at the appropriate time.
> >
> > Metadata is routed differently from data so that such association is
> > avoided.
>
> I was talking about the server from which both the search and the data request
> orginate.
OK, I'm taking the time to explain this more fully so that you can check my
assumptions.
Design Goal: To allow a search hit on metadata item to promote that item in a
server's LRU list, but only if the underlying data is actually requested.
Additional Requirements:
- Don't allow metadata to give away any information about the physical
location of underlying data.
- Don't give away any information about who is searching for what
- Minimize the number of server-to-server messages
- (this list should be longer)
This is my understanding of what happens when a metadata search is done:
A client connects to a Freenet server and requests a search. The search
fans out from the originating server and eventually matches successfully against
some metadata items. These are sent back to the originating server, which
passes them back to the client. The client chooses one that is interesting,
and, using the data item key conveniently packaged with the metadata,
requests the data item. Presumeably the data request is made through the same
server as the search. The request winds its way across Freenet, taking a route
not at all related to the metadata, and eventually hits a server that has the
data item. The server promotes the data item in its LRU list and sends it back
up the chain to the originating server, which passes it to the client.
Now we want to add to this the behavior that the metadata item used to find
the data is also promoted in a LRU list.
We don't want the client to be responsible for this because the policy the
client will use is completely unknown and possibly malicious.
Other than the client, there is only one place where the data and metadata
paths converge: at the originating server. The originating server is thus best
positioned to make an association between the data and metadata, and to cause
the metadata to be promoted. The association is easily made, as I described
before. In fact, the originating server could just store the relevant metadata
at this point and it would not disappear from the net. It would, however,
become rather hard to find so this isn't the best thing to do.
We therefore need to know the metadata item's key so a special message can be
sent that retraces the route back to the metadata and promotes it. This is
easily accomplished by including metadata keys with the metadata items
returned from a search request.
Did I make any invalid assumptions here? If not, this seems to me to be a
robust and efficient way of handling metadata promotion.
--
Daniel
--__--__--
Message: 18
From: [email protected]
Date: Sun, 25 Jun 2000 17:25:35 -0700
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata (was: Meaningless hits)
Reply-To: freenet-dev at lists.sourceforge.net
Daniel writes:
> Design Goal: To allow a search hit on metadata item to promote that item in a
> server's LRU list, but only if the underlying data is actually requested.
>
> Additional Requirements:
> - Don't allow metadata to give away any information about the physical
> location of underlying data.
> - Don't give away any information about who is searching for what
> - Minimize the number of server-to-server messages
> - (this list should be longer)
>
> This is my understanding of what happens when a metadata search is done:
>
> A client connects to a Freenet server and requests a search. The search
> fans out from the originating server and eventually matches successfully
> against
> some metadata items.
Whether searches should "fan out" has been controversial. I believe
the latest proposals have no fan out, rather the search takes a linear
path through the network just like any other request. The difference
is that the search may return multiple hits, whereas a normal request
stops as soon as it sees one hit. Also, the comparison algorithm used
by the search routing may be different so as to allow finding results
which are close to but not exactly what is searched for.
> Now we want to add to this the behavior that the metadata item used to find
> the data is also promoted in a LRU list.
>
> We don't want the client to be responsible for this because the policy the
> client will use is completely unknown and possibly malicious.
The other mistake you are making, which is more fundamental, is that in
most cases the client and the server will be on the same computer, and
controlled by the same person. We hope that most Freenet users will be
running nodes. This benefits the network and also benefits the person,
as it gives him more deniability.
This means that you cannot trust a random node any more than a random
client, and therefore you might as well do this in the client if you
are going to do it at all. Nodes are no more trustworthy than clients.
> In fact, the originating server could just store the relevant metadata
> at this point and it would not disappear from the net. It would, however,
> become rather hard to find so this isn't the best thing to do.
Actually, by default, data is in fact stored along the path where it
is returned, so what you are calling the originating server would in
fact store the relevant metadata if we didn't override this behavior.
I am not sure whether search-return metadata would follow this policy
or would be an exception, though.
> We therefore need to know the metadata item's key so a special message can be
> sent that retraces the route back to the metadata and promotes it. This is
> easily accomplished by including metadata keys with the metadata items
> returned from a search request.
So here is the meat of the idea: create a message which boosts metadata.
And perhaps, don't boost metadata when it gets returned as part of
a search.
We had a long debate earlier about a very similar proposal, although that
was in the context of ordinary data. It was suggested that rather than
automatically promoting fetched data, it would be better to separate the
promotion from the fetch. Only after you had fetched it and verified
that the data was what you wanted would you send the promotion message.
This is to protect against the Popescu attack where he posts messages
under invalid labels.
I'm not familiar enough with the various proposals to say whether this
is a good idea in the case of metadata. The one thing I'd add is that
you don't need a metadata key to do it, and in fact that would be the
wrong way. You probably want to retrace the path you followed when you
did the search. For that the metadata-boost message should be routed
in exactly the same way as the search was, using the original search
terms and the same fuzzy closeness relationships.
Hal
--__--__--
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
End of Freenet-dev Digest
