Deletion, GC and placement

1. Deletion is an asset tombstone

Deleting an asset is an ordinary SOP/1 equality delete of its asset_id in the governing metadata table named by asset_table in the object manifests. All of SOP/1 section 14 applies verbatim: the tombstone is permanent identity knowledge, order-free, and immune to late-arriving objects — a blob object surfacing from a long-offline device cannot resurrect a deleted asset, because acceptance into queryable state checks the tombstone set regardless of arrival order.

Consequences for the blob plane:

1. A blob object whose asset_id is tombstoned in its governing table MUST NOT be served to queries or displays, and becomes eligible for physical garbage collection — original and derivatives alike, since they share the asset_id.
2. asset_id values MUST NOT be reused (section 14.7). Re-importing a deleted photo mints a new asset_id; plaintext-identical bytes are a new asset.
3. The user-facing meaning of “deleted” MUST distinguish the four states of section 14.8: logical deletion applied, managed ciphertext removed, key material destroyed, acknowledgement received. Blind replicas holding ciphertext of a deleted asset are state two pending, not state one violated.

2. Supersession is derivative-only

Blob objects are never compacted: there are no small objects to coalesce, no rows to physically purge, no rewrite amplification. An original is published once and either lives or is deleted. This removes the hardest machinery of the tabular plane — none of section 18’s confidential compaction applies to blobs.

The only supersession the blob kind permits is derivative regeneration: a better thumbnail, a re-transcode. The replacement derivative’s manifest lists the replaced object in supersedes[]; an original MUST NOT be superseded.

Derivative supersession also escapes the verified-GC problem. For tables, section 18.5 exists because a malicious compactor can silently drop live rows and the sources are then destroyed. A superseded derivative destroys nothing: it is recomputable from its derived_from source, which remains live. Therefore:

• a superseded derivative MAY be garbage-collected once the superseding object’s bytes are durable under placement policy, without a second-replica attestation;
• GC of an original (only via asset deletion, never supersession) follows the ordinary section 19 rules for tombstoned data.

A regeneration that would change which bytes an entitled device can recover — for example superseding a transcode whose source original was placement-lost — does not qualify for the relaxed rule; if the derived_from source is not durably held, the superseded derivative MUST be retained as if it were an original.

3. Garbage collection

The GC preconditions of SOP/1 section 19 apply, with eligibility determined per asset:

GC-eligible(blob object O) =
    tombstoned(O.asset_id in O.asset_table)
    or (O in supersedes[] of a durable derivative
        and O.derived_from source durably held)

Because asset_table is named in the immutable manifest, a storage node that can decrypt the catalog can compute eligibility locally; a blind replica cannot, and follows instructions from decrypting members — the same division as for tabular GC. Blind replicas SHOULD retain ciphertext until an authorized member confirms eligibility, mirroring the default retention posture of section 18.5.

Key destruction composes: once every object wrapped under a KEK generation is GC-complete, generation retirement proceeds under the ordinary lazy rules of section 7.6.

4. Placement

The scope/placement split of SOP/1 section 16 is the part of the base plane that media needs most, and it needs no modification — only a worked default:

photos asset class

scope (decryption):
    laptop            originals + derivatives
    phone             originals + derivatives
    wall-display      derivatives only (preview domain)

placement (ciphertext):
    phone             thumbnails: all; originals: 90-day hot window
    laptop            full
    home-node         full, blind acceptable
    archive           full, blind

Placement policy SHOULD treat derivative kind as a first-class input: the thumbnail set is small enough to pin everywhere and is what interactive browsing touches; originals follow a hot-window policy on constrained devices, with cold fetches served on demand as verified range transfers.

5. Object sizing

The 16-64 MiB object-size target of SOP/1 section 13.3 is a batching policy for row data and does not apply to blobs. A blob object is its asset’s natural size: a 4 GiB video is one object. The transfer layer is built for exactly this — content addressing gives resumable, verified, range-addressed transfer regardless of object size — and splitting an asset across protocol objects would only reinvent the container formats media already has.

Very large objects still deserve two operational notes:

• publication durability (ciphertext durable locally before catalog entry, section 13.2) means a device must hold its own asset until a replica confirms; placement policy on capture devices SHOULD prioritize evacuating large originals to storage-rich nodes;
• the Padmé overhead bound (at most ~12%, decreasing with size) is paid per object; for multi-GiB objects the absolute overhead is real storage and SHOULD be reported by implementations.