On Mon, May 07, 2001 at 11:07:51PM -0500, Brandon wrote:
> There is no expense in requesting an additional file if the files are
> requested simultaneously, at least no expense worth mentioning.
There is if one of them has been dropped - and how will you know what
metadata file to request before you have requested the first file?
Also, what is to stop client writers just embedding the metadata in the
document themselves? That is what i'd do - and that doesn't solve the
problem you outline.
> The first problem doesn't seem like a real practical problem (who's going
> to use this attack and what purpose will it serve?) but still seems pretty
> dumb and should probably be avoided.
You are right, it is dumb, and so I don't even see why you mentioned it,
it doesn't serve your argument.
> The second problem will come up a lot when we start attaching DMI to files
> since even a difference in capitalization or punctuation of the name of
> the author or title will cause the network to store an additional copy of
> the file. This will in effect cause popular files inserted by different
> people to split the popularity vote that should really be going to a
> single file.
>
> The only way to fix both problems is to eliminate metadata from CHKs.
As we both agree, the first problem isn't a problem. Further, I don't
think that the second problem is really all that serious either, can you
outline why this would be such a bad thing? Even if there were two
files that were similar but not idential, and thus they were stored
under 2 CHKs, requests for each would be divided between the two, so
they wouldn't be any more widely propogated than were they the same
file. Of course they might fall out faster, but I don't think that is a
serious consideration compaired to the annoyance of trying to separate
out metadata.
The real solution to this is either to forget about it, since it isn't
that serious a problem, or if you must, stipulate that all metadata keys
are listed in alphabetical order, and the keys are all lower-case (also
encourage data to be lower-case unless both cases are required).
> This can be done without increasing request time by putting the key for
> the metadata file in the CHK.
This would work, but it is a slippery slope, and as I have noted, is
hardly nescessary - why not just put *all* the data in the CHK and
forget about Freenet altogether?!
Ian.
PGP signature
