Dave Noha <dave at c-c-s.com> wrote: > I'd like to add: > 3) Stuffing metadata in the trailing segment leads to a data reuse > problem. If my client dumps a bunch of extra headerish-type fields in > front of the actual data, no other client can use that data unless it > understands those headers too. > > I see a few solutions to these problems: > A) Standardize a format for metadata in the trailing segment. To quote > Brandon: > > > > I think the format for the information in the trailing field should be > > just like in a message, that is fields following by a trailing field. > > > That sounds good to me; the only thing clients would have to understand > is where the real data begins.
The format you pick should also have a simple way to specify the sending of data alone, with null metadata. > B) Encrypt important metadata in some way and put it in Storable fields > in the real header. > > C) Define a separate header section (someone used the unappealing phrase > "body-header" earlier) that's encrypted somehow, but distinct from the > trailing segment, so nodes can deal with it independently of the > trailing segment. The problem with B and C is that when you are encrypting very short plaintext strings whose content is known or guessable (e.g. "Content-type: text/plain"), you provide a great handle for cryptanalysis. (For example, the Allies in WWII used to bomb certain cities with very distinctive names just to provoke encrypted traffic containing those words. =) You might need to pad them out with some random gibberish. > The advantage of methods B and C is that they would support a > header-only request, whereas A could not, because the metadata would be > in the trailing segment which can't/shouldn't be looked into by nodes. You could do A, but have the nodes split apart the metadata and data on receipt and store them separately. Then concatenate them together (or not) on replies. theo _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
