Skip to content
cccskills
FreePublished on GitHub

content-addressable-storage-immutability

CRITICAL: Never modify files in content-addressable storage systems where the filename IS the content hash (SHA256, IPFS CID, etc.). Use when: (1) Working with Blossom protocol, IPFS, or any CAS system, (2) Considering "optimizing" stored files (faststart, compression), (3) Implementing transcoding or processing pipelines for hash-identified content, (4) Building on top of ProofMode or any cryptographic verification system. Modifying files in place breaks hash verification and content integrity.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md3.9 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Content-Addressable Storage Immutability

Problem

In content-addressable storage (CAS) systems, files are identified by their content hash. If you modify a file in place (even "harmless" optimizations), the content no longer matches its identifier, breaking the entire system's integrity guarantees.

Context / Trigger Conditions

  • Working with Blossom protocol (files at /{sha256})
  • Working with IPFS (files at /ipfs/{CID})
  • Any system where filename = hash of content
  • Considering file optimizations like:
    • MP4 faststart (moving moov atom)
    • Image optimization/compression
    • Metadata stripping
    • Format conversion
  • Systems using ProofMode or cryptographic verification

The Fundamental Rule

NEVER modify a file stored at its content hash.

The hash IS the identity. Change the content → change the hash → file is now at wrong address.

What Goes Wrong

Original file: abc123... (hash) → contains bytes X
After "optimization": abc123... (hash) → contains bytes Y

Result:
- Hash abc123 no longer verifies
- ProofMode signatures invalid
- Content-addressable lookups return wrong data
- Cryptographic proofs broken
- Data integrity compromised

Solution: Store Derivatives Separately

If you need optimized/processed versions, store them at separate paths:

/{hash}                    ← Original file (NEVER MODIFY)
/{hash}/hls/master.m3u8    ← HLS transcoded version
/{hash}/faststart.mp4      ← Faststart optimized version
/{hash}/thumb.jpg          ← Thumbnail
/{hash}/720p.mp4           ← Resolution variant

The original stays byte-for-byte identical. Derivatives live in subdirectories.

Implementation Pattern

// WRONG - modifies original
async fn process_video(hash: &str) {
    let path = format!("/{}", hash);
    let video = download(&path);
    let optimized = apply_faststart(video);
    upload(&path, optimized);  // ❌ BREAKS HASH!
}

// RIGHT - creates derivative
async fn process_video(hash: &str) {
    let original_path = format!("/{}", hash);
    let derivative_path = format!("/{}/faststart.mp4", hash);

    let video = download(&original_path);
    let optimized = apply_faststart(video);
    upload(&derivative_path, optimized);  // ✓ Original untouched
}

Verification

  • Original file hash still verifies: sha256sum file == filename
  • ProofMode signatures still valid
  • Content lookups return expected data

Common Mistakes

  1. "It's just moving metadata" - Still changes bytes, still breaks hash
  2. "We'll update the hash reference" - Now you have dangling references everywhere
  3. "No one will notice" - Verification systems WILL notice
  4. "It's an optimization" - Optimize derivatives, not originals

Notes

  • This applies to ANY content-addressable system, not just Blossom
  • IPFS, Git objects, Docker layers all follow this principle
  • If you need the optimized version as primary, the client should upload it that way
  • Transcoding to new formats (HLS, DASH) is fine because they're clearly separate files

References

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Fix ArgoCD ExternalSecret deployment failing with "namespace X is not permitted in project Y". Use when: (1) ExternalSecret shows OutOfSync in ArgoCD but won't sync, (2) ArgoCD application status shows "namespace X is not permitted in project 'infrastructure'", (3) ExternalSecret targets a namespace managed by a different ArgoCD project, (4) Using apps-of-apps pattern with separate infrastructure and application projects.

The English summary is being prepared. Showing the original description.

divinevideo/divine-mobile266Updated Oct 19, 2026

Art direction for any content — reads text, PDF, Word, HTML, PPT, then proposes 2-3 creative directions with photography style, mood, and visual language. After selection, generates AI image prompts and visual briefs section-by-section. Use when the user shares content and needs visual direction, image sourcing, or creative direction for any material.

The English summary is being prepared. Showing the original description.

divinevideo/divine-mobile266Updated Oct 19, 2026

Fix "Null check operator used on a null value" errors when an object is set to null during an async await. Use when: (1) Object reference is nullified while awaiting, (2) Code accesses object with ! after await returns, (3) Cancel/dispose operations run concurrently with async operations on same object. Solution: capture local reference before await.

The English summary is being prepared. Showing the original description.

divinevideo/divine-mobile266Updated Oct 19, 2026

Add custom metadata headers (x-amz-meta-*) to AWS v4 signed requests for GCS S3-compatible API. Use when: (1) Adding custom metadata to GCS uploads via S3 API, (2) Getting signature mismatch errors after adding new headers, (3) x-amz-meta-* headers being ignored or causing 403 errors. Custom headers MUST be included in canonical headers and signed headers list.

The English summary is being prepared. Showing the original description.

divinevideo/divine-mobile266Updated Oct 19, 2026

Fix password/secret authentication failures caused by trailing newlines when creating Google Cloud secrets (or similar) with bash here-strings. Use when: (1) Password authentication fails with correct password, (2) Secret created with `<<< "value"` syntax, (3) Error like "password authentication failed" or "invalid token" despite correct value. Bash here-strings (`<<<`) add a trailing newline that corrupts secrets.

The English summary is being prepared. Showing the original description.

divinevideo/divine-mobile266Updated Oct 19, 2026

Fix silent video/media processing failures caused by URL extraction code that filters on file extensions (.mp4, .webm, .webp). Use when: (1) Media moderation, transcoding, or analysis silently skips files from Blossom or content-addressed storage servers, (2) URL extraction from Nostr event tags (imeta, r tags) drops URLs without recognized extensions, (3) CDN fallback URLs append .mp4 but the actual server uses extensionless content-addressed paths like /{sha256}. Common in Nostr video events (kind 34236) where different clients use different URL formats.

The English summary is being prepared. Showing the original description.

divinevideo/divine-mobile266Updated Oct 19, 2026

See all skills by divinevideo

Report a problem with this skill