> 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 Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
