Re: [Gzz] Raw pools?

[Benja Fallenstein]

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.)

> > 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.

> 2. Storm and crypto: signatures, identities

What's this?

> 3. Storm and Xanalogical media

Ok.

> 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.

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

> > 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:

> > 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. ;-)

- Benja