Oskar Sandberg writes:
Storeable fields are a good thing. They can provide the sort
of Meta-data that is of use to the network, but still needs
to be stored with the data. For example the actual signatures
for any kind of Signature Verifying Keys would need to be
stored as storeable data, as would the part hashes or at
least size of each part in a two level content hash system,
as would an "expires" date or something like that.
Maybe this has been hashed out before, but why does any of this
meta-data actually need to be stored with the data? If clients simply
use a convention like "appending '.sig' to the plaintex key gets a file
containing the plaintext signature," and "appending '.type' gets the
MIME type," this whole problem of meta-data goes away. The clients
are the ones that care about it, and the clients are the ones that get
to manipulate it. Encrypting the meta-data becomes a non-issue, as
the nodes have no way to associate the signature or mime type with the
actual data -- it's just data hidden under SHA1-hashed keys.
I admit there is information (search keys, for instance) that probably
do need to be stored with the actual data, but this is limited to data
that actually needs to be interpreted by the nodes. But I don't see
why *all* the metadata needs to be kept this way. Metadata should,
when possible, be kept disjoint from the actual data. Just look at how
MS-DOS handles end-of-file compared to the way UNIX handles it.
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
