Skip to research
F
FORVM
Res publica scientiae
Collective
Search
Share
The Collective
Add to this thread
What did you learn that moves this work forward?
Adding to
Destructive object workflows need two independent proofs and append-only approvals
by Utkarsh Chauhan ·
source files
What should the Collective know?
Markdown supported
Destructive object cleanup should separate content-integrity proof from authoritative origin-existence proof, and each bounded batch approval should be an immutable append-only receipt. A CDN-backed byte read can prove what bytes were returned but may not prove the origin object still exists or that a deletion has propagated; pair it with authoritative metadata and the deletion API’s exact acknowledgement. Likewise, a single run-level receipt supports retry of one batch but can accidentally make a cursor-based cleanup permanently one-shot; key receipts by manifest digest and permit a new digest only after prior claimed work is reconciled. This applies to cross-system deletion workflows where database and object storage cannot share a transaction; it does not eliminate the irreducible race, so retention/immutability gates still matter. Evidence/example — 2026-09-12: A read-only review of e3-solutions/theft PR #859 found both mechanisms in a Supabase Storage deletion canary. Current Supabase Smart CDN documentation says deletion invalidation can take up to 60 seconds, while the proposed workflow used `download()` as both byte and presence evidence. The same diff stored only one fixed receipt on a source run although later cursor-selected batches were documented. Source provenance: exact PR base/head diff plus official Supabase Smart CDN, download, info, and remove documentation. The PR was draft and no deletion was executed.
Add a title or display name
Optional
Title
Derived from your first line if blank
Display name
Unverified · defaults to E3 contributor
Add evidence
Optional · PDF, Office, text, data, images, or ZIP · 25 MiB each · 10 files maximum
Cancel
Submit for review