Re: [Gzz] Raw pools?

[Tuomas Lukka]

> Hmm...
> 
> - Storm core

What's that?

> - Concept and rationale: Blocks to move easily between pools

Between pools?? 

> - The persistency commitment

Yes

> - API

Which one?

> - Block format (header with content-type, opaque body), id format
> - Backward compatibility: Old specs we need to continue to support
> - Applications
> - Pointers [could possibly be a single PEG]
> - Concept: rich branching versioning without central repository
> - Pointer block format
> - API
> - Challenges when used on the network
> (digital signatures; what to do if not all pointer blocks are known)
> - Diffs
> - Xanalogical media
> - Concept: Content stored in blocks, other blocks refer to it
> (and there's a reverse indexing mechanism for referals)
> - Formats
> - API

Again?

Hmm, was there some indentation missing?

> 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
2. Storm and crypto: signatures, identities
3. Storm and Xanalogical media

Implementation

1. Storm block format
2. Storm pointers layer 1: no crypto, nothing except branching versioning

> >>I still don't agree that this makes a big difference *at this point in 
> >>time*. So far, I have *never* entered a SHA-1 in a 
> >>content-based-retrieval system. Besides, if the papers used in xupdf 
> >>were available in one, that would be illegal, while they're also legally 
> >>available from the respective web sites *we* got them from-- except if 
> >>the copyright holders would make them available there, which isn't 
> >>paricularly likely.
> >>
> >>I'm saying this to explain why I'm still not convinced we should change 
> >>Storm at this time. Can you explain why you feel this is so important 
> >>right now?
> >>   
> >>
> >
> >Yes.
> >
> >I want to be able to *now* make a *permanent, eternal* link which uniquely
> >identifies a file, which I can't unfortunately redistribute, 
> >
> >So that if someone enters all the files on their disk to a SHA-1 index,
> >they'd get a hit.
> >
> >So that anyone who *does* have access to the file can verify that it *is* 
> >the same
> >file that I made the link to.
> >
> >The permanence is the point.
> >
> 
> 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.

And also so that the header block can be redistributed.

> >Canonical blocks (with trivial header) feel like a very unclean solution;
> >I expect that sha-1 of files will see much more use in a few years.
> >
> 
> It *may* very well. However, as I said I'm for being as conservative as 
> possible in changing the Storm spec, meaning: Only change it when the 
> change is needed right now-- not because of an anticipated need or a 
> cool new idea, even if it seems extremely probable that this new feature 
> will be needed in the future. Only place the additional burden on the 
> shoulders of future implementors if you *know* it is necessary.
> 
> 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.

That's why I think we should probably get rid of canonical blocks *right now*.

They were probably a wrong solution.

        Tuomas