On Fri, May 11, 2001 at 05:34:04PM +0200, Oskar Sandberg wrote:
> On Fri, May 11, 2001 at 08:45:33AM -0500, [EMAIL PROTECTED] wrote:
> > On Fri, May 11, 2001 at 01:40:13AM -0500, Scott Gregory Miller wrote:
> <>
> > > Thats hardly a reason. If the metadata points to the CHK of the data
> > > thats an equally strong binding.
> > >
> >
> > No it's not. It's only an assertion by whomever inserted the metadata. For the
>binding
> > to be equally as strong, the data would also have to refer back to the CHK of the
>metadata.
> > Then the agreement between inserter of data and inserter of metadata would be
>proven.
>
> Bullshit. I can copy your CHK and insert new metadata linking to that CHK,
> but I can also copy all the data add new metadata and insert the whole
> thing. Why does it matter for two fucking seconds what the inserter of the
> data thought when ANYBODY can reinsert it?
>
> The ONLY assertion you have is by the person whomever owns the key you
> started out with requesting belongs to.
>
I thought that the point of a CHK is that duplicate data can't be re-inserted.
Generating a CHK on anything except the data is pointless and counter productive,
for exactly the reason you give above.
Whatever cruft gets attached to data to get it in to and out of Freenet, or to describe
the data, should not be used to generate the data's identifier.
If you want to identify the entire package, data+cruft, that's fine, but it's not
all that meaningfull. It gives some temporal assurances, i.e. this is the same package
that it was yesterday, but so what? It doesn't carry any information specifically
about the data, and when you get right down to it the data is the whole darn point of
the exercise.
1) generate the CHK only from the data
2) the rest of the stuff becomes irrefutable, because if you change it and try to
re-insert, it will (should) collide.
3) If for some reason you want two packages, then bi-directional references will
maintain the same strength of the associations (there is agreement between the two
parts)
4) Unidirectional references from the data to one or more meta-data packages are almost
as strong, because for this argument we are using a 'data-centric' viewpoint. The
weakness
here is the 'you stole my meta-data' case, referring to something without permission or
agreement, but I'm not sure how meaningfull that is
5) Unidirectional references from metadata to data are untrustable assertions.
David Schutt
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
