> stone the metadata permitted with documents. The reason is that if we
> don't allow metadata, client authors will be forced to place that
> information in the document itself (to avoid the expense of requesting
> an additional file), and we are back to the exact same situation.
There is no expense in requesting an additional file if the files are
requested simultaneously, at least no expense worth mentioning.
The benefits are: 1) the first inserter can't determine in a totalitarian
way what the metadata of a file is. 2) The network will not store multiple
copies of the same file with differing metadata (because metadata will be
in a different file).
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.
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.
This can be done without increasing request time by putting the key for
the metadata file in the CHK.
The only complaint about it so far is that CHKs are too long. That is a
really lame reason for rejecting the proposal. Why should we care how long
CHKs are? They're not human readable as it is.
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
