Re: [Gzz] Raw pools?

[Tuomas Lukka]

On Sun, Nov 17, 2002 at 10:46:17PM +0100, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >>- Concept and rationale: Blocks to move easily between pools
> >>   
> >>
> >
> >Between pools?? 
> >
> 
> Yes, so? (Whenever a block moves, it moves between pools? Except if a 
> pool moves physically, such as moving a disk to a different place, which 
> is not interesting to consider.)

Oh, my definition of pool was "all mediaserver repositories anywhere with
the same pool ID" -- more virtual.

So you mean moving between physical locations?

> >>Quite a suite. Would greatly help people trying to understand what we're 
> >>up to, though.
> >>   
> >>
> >
> >How about starting with
> >
> >High-level
> >
> >1. Storm concept and rationale
> >     - eternal blocks, moving easily
> >
> 
> Should also have the commitment PEG at the same time.

Well, that *could* also be later, as making this more exact.

> >2. Storm and crypto: signatures, identities
> 
> What's this?

The overall intent on how Storm is supposed to work with crypto.

> >Implementation
> >
> >1. Storm block format
> >2. Storm pointers layer 1: no crypto, nothing except branching versioning
> >
> 
> Should also have the pointer concept PEG then. Describing the formats 
> without the rationale doesn't make much sense.

I didn't say formats here. This *would* be the concept. ;)

> Also, 'implementation' is a misnomer: 'Formats' would be better.

Well, then the above pointers thing shouldn't be here.

> >>Would making "these blocks are the same"-style links and signing them 
> >>digitally not work?
> >
> >We don't have that yet.
> >
> >I want to be able to have it working *right now* so that someone can just
> >plug in a file they got from somewhere.
> 
> Well, I won't convince you by reiterating my points, so it seems that we 
> have to introduce the new format. But I still don't agree with your 
> reasoning, since they *can* plug in the file if they got it from somewhere:
> 
> java gzz.mediaserver.AddToMediaserver -c Z/ guess article.pdf
> 
> What they cannot do is to write a program that automatically requests 
> this from a library which takes the SHA-1 of the block's body. However, 
> I don't know anybody who wants to do this *now*. So "we don't have that 
> *yet*" does not make a difference. Heck, even if someone *wanted* to do 
> it right now, we could make a mapping from the canonical blocks' ids to 
> their bodies' hashes; then those files could be requested from the 
> library (e.g., content distribution network) and inserted as canonical 
> blocks.
> 
> I do think that we will want to have the header/body separation, but:

Ok.

> >>With this, at the time this is in common use it's entirely possible that 
> >>a new, more efficient way of doing this has been found, and we will 
> >>*have* to support it-- which would mean *two* more formats to support by 
> >>implementers, because the format introduced now would also have to be 
> >>supported.
> >>
> 
> Now, you replied to that by saying:
> 
> >That's why I think we should probably get rid of canonical blocks *right 
> >now*.
> >
> 
> But how does this relate to what I write above? I wrote it as a reason 
> for *not* moving to something new, so if you think it's a reason for the 
> opposite, you *should* say why :-) :-).
> 
> >They were probably a wrong solution.
> > 
> >
> 
> The decision was based on exactly the points made here, and I obviously 
> still think they're true. ;-)

Ok. Canonical blocks are bad, because

        1) they don't solve the problem of getting the unadulterated data's 
SHA-1
           except through new features which just make things more complicated
           (everyone has to support those mappings etc!)
        
        2) they have a part of the normal header but not all; everyone needs to 
support
           that as well.

I think they get us *more* complexity than the header-block separation would,
so it might be good to ditch them *now*.

        Tuomas