Design rudimentary delta (V2) #410
Description
Whilst we expect access patterns to improve (likely in V3) for random access patterns on the content store of a raw .stone, that isn't a blocker for implementing basic deltas in V2.
The type flag for Delta has been reserved in the container format for some time, and could quite trivially be implemented today. Of course, this format implementation is a separate issue to making delta packages visible in the index and usable by the client.
Long story short, a .delta.stone would be a regular stone with the header-type set to Delta, containing the Layout+Meta payloads of the input stone B. A new content payload (and associated index payload) are generated, containing only the addressable assets (xxh128) that exist only in stone B and not in stone A.
Given that we'll ensure stone A was already cached in the client install before allowing the delta to B to be used, we can rely on using stone B's layout references to stone A's addressable content in the local cache.
Thus: Delta C blobs = B ~ A
For implementation in the client side, we'll also need Meta Payload record(s) to describe the DeltaOrigin and DeltaTarget to assert the delta is valid for the two inputs.