>
> Anyway, I've implemented the separate metadata (not attached to
> files) insert and request.
This is good, and to calm Oskar's fears, I'm hoping you mean separate,
clear metadata, the kind that would need to be indexed for searching.
> I also have a really neat structured query parser that returns a list of
> all keys matching queries of the form
> ((author=Brandon)&((timestamp<20001026)|(timestamp>20001220))). I don't
> have a use for this at the moment, but it's pretty neat.
I don't see a use for it either, yet.
> Next I'm going to make the clients actually use the metadata attached to
> files, do automatice separated metadata insertion and retrieval along with
> data insertion and retrieval, and write a file server node to keep
> information in Freenet.
You do know that this is complete in Insert and RequestClient in the tree,
right? I am having some weird problems with the node rejecting inserts
now, w/ cache.isReadable() returning false. The only way that can seem to
happen is if the amount of received data differs from the length the
client said the file would be. Any help tracking this down would be
greatly appreciated, as it seems that my end (the client) is transmitting
the same amount of data specified in DataLength.
Also, we need to clean up the abstraction in the clients so that
SimpleClient/Freeloader can benefit from the addition of crypto and
metadata within Insert/RequestClient.
Just so you guys know, I added two commandline flags to the clients:
-metadata file
In insertclient, this attaches 'file' as private metadata on the
insert.
This causes the storable field Metadata-length to be attached to the
document, whose semantics are obvious.
On request, if Metadata-length is present, the client will write the
metadata to 'file', or standard out if "-" was the file. If the
-metadata flag wasn't specified the metadata is skipped.
-cipher name
In insert client only. This flag specifies the cipher you wish to
use to encrypt the document (note that a Freenet document contains the
structure specified below... it includes both the metadata and document
data)
Any 'name' that names a BlockCipher subclass in Freenet.crypt.ciphers
is fair game. Currenty, that means Twofish or Rijndael. (Twofish is
the default)
The document is encrypted with that cipher, and the storable field
'Symmetric-cipher' is set to the name of the cipher. On request,
the client reads that storable field to find out how to decrypt the
document.
A freenet document is of the following structure (ignore newlines):
<2-octet keylength L>
<L key bytes>
[optional private metadata]
<Data>
For those who weren't around when we decided this (namely anyone but
Oskar and maybe Adam), the key is included in the document so that when
she begins receiving data, Alice can decrypt the document
(including the key) with the key, and verify that the key she is using is
the same as the one stored with the document. If they don't match, it
means that the document was tampered with, or unencrypted, both of which
are Bad Things(tm). At this point, Alice aborts immediately, without
having to transfer any more data. This doesn't mean that we also don't
uses Oskar's two-level-hashing stream, because the storable key only
prevents full document replacement or preventing unencrypted data. The
two-level scheme catches modifications throughout the document.
> The first is so that we can get ContentType usable again. The last is so
> that people will just stop asking about it.
The only thing I have against putting ContentType in the private
(attached) metadata as Oskar suggests is that it means we're specifying
what has to be in the attached metadata. I'd rather it be a freely usable
field. However, it would be nice to have private storable
fields. Perhaps I should extend the metadata to be simply a multipart
document, and we could have a storable field name Private-storables that
pointed at which part contained a list of the private storable fields?
Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20000523/4769af9f/attachment.pgp>
