Identificatori di Contenuto (CID)

L'impronta digitale unica che ogni file IPFS riceve.

Cos'è un CID?

Un Content Identifier (CID) è un'etichetta auto-descrittiva che identifica univocamente un dato su IPFS. Deriva dall'hash crittografico del contenuto del file, combinato con metadati sull'algoritmo di hashing e sul formato di codifica utilizzati.

bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

I CID che iniziano con bafy (o bafk per contenuti di piccole dimensioni a blocco singolo) usano CIDv1, il formato moderno auto-descrittivo. I CID legacy che iniziano con Qm usano CIDv0 (SHA-256 codificato in base58) — ancora validi, ancora risolvibili, ma non più il formato di output predefinito per i nuovi contenuti.

Proprietà chiave

• Deterministico — Lo stesso file produce sempre lo stesso CID. Carica la stessa immagine due volte e ottieni lo stesso identificatore.
• Unico — Anche una modifica di un singolo byte produce un CID completamente diverso. Questo rende i CID a prova di manomissione.
• Auto-verificabile — Chiunque riceva un file può ricalcolare l'hash e confermare che corrisponde al CID richiesto.
• Immutabile — Un CID punta sempre allo stesso contenuto. Non puoi cambiare a cosa un CID si risolve.

I CID in IPFS.NINJA

Ogni file che carichi restituisce un CID nella risposta API. Usalo per:

• Accedere al file tramite gateway: ipfs.ninja/ipfs/<CID>
• Recuperare i metadati del file: GET /file/<CID>
• Fare riferimento al contenuto on-chain (NFT, smart contract)
• Condividere con chiunque — potranno verificare che il contenuto corrisponda

CIDv0 vs CIDv1

Proprietà	CIDv0	CIDv1
Prefisso	Qm...	bafy... (dag-pb, directory e file multi-chunk), bafk... (raw, contenuti piccoli a blocco singolo), più altri in base al codec
Funzione hash	Solo SHA-256	Multiple (SHA-256, Blake2b, ecc.)
Codifica	Base58 (maiuscole e minuscole miste)	Multibase — base32 di default (minuscolo, DNS-safe)
Auto-descrittivo	No	Sì (include codec + info hash)
Chunker	256 KiB (default legacy)	1 MiB secondo IPIP-0499
Codifica delle foglie	Incapsulata in dag-pb	Byte raw (raw-leaves=true)

Cosa emette IPFS.NINJA

I caricamenti e i pin effettuati dopo il 2026-07-13 restituiscono CIDv1 come formato predefinito: codifica CIDv1 base32, chunk da 1 MiB, foglie raw — il profilo IPIP-0499 unixfs-v1-2025. Implicazioni pratiche:

• I file piccoli (≤ 1 MiB) vengono restituiti come bafk... (CIDv1 raw a blocco singolo)
• I file più grandi e le directory vengono restituiti come bafy... (CIDv1 dag-pb)
• Un file caricato tramite il nostro servizio ottiene lo stesso CID che qualsiasi strumento moderno (Helia, l'ultima versione di Kubo, ipfs-car) calcolerebbe a partire dagli stessi byte

Compatibilità con le versioni precedenti

I CID legacy Qm... provenienti da caricamenti precedenti restano completamente risolvibili — il gateway, POST /pin, GET /file/:cid, i resolver IPNS e tutti gli altri endpoint accettano entrambi i formati a tempo indefinito. Se hai un CID Qm... da un caricamento precedente, nulla di quello che hai costruito smette di funzionare.