Identifiants de contenu (CID)

L'empreinte unique que reçoit chaque fichier IPFS.

Qu'est-ce qu'un CID ?

Un identifiant de contenu (Content Identifier, CID) est une étiquette auto-descriptive qui identifie de manière unique un élément de donnée sur IPFS. Il est dérivé du hash cryptographique du contenu du fichier, combiné à des métadonnées sur l'algorithme de hachage et le format d'encodage utilisés.

bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Les CID qui commencent par bafy (ou bafk pour le contenu à bloc unique de petite taille) utilisent CIDv1, le format moderne auto-descriptif. Les CID hérités qui commencent par Qm utilisent CIDv0 (SHA-256 encodé en base58) — toujours valides, toujours résolubles, mais ne sont plus le format de sortie par défaut pour le nouveau contenu.

Propriétés clés

• Déterministe — Le même fichier produit toujours le même CID. Téléversez la même image deux fois et vous obtenez le même identifiant.
• Unique — Même un changement d'un seul octet produit un CID complètement différent. Cela rend les CID infalsifiables (tamper-evident).
• Auto-vérifiable — Toute personne recevant un fichier peut recalculer le hash et confirmer qu'il correspond au CID demandé.
• Immuable — Un CID pointe toujours vers le même contenu. Vous ne pouvez pas changer ce vers quoi un CID se résout.

Les CID dans IPFS.NINJA

Chaque fichier que vous téléversez renvoie un CID dans la réponse de l'API. Utilisez-le pour :

• Accéder au fichier via le gateway : ipfs.ninja/ipfs/<CID>
• Récupérer les métadonnées du fichier : GET /file/<CID>
• Référencer du contenu on-chain (NFT, contrats intelligents)
• Le partager avec n'importe qui — cette personne peut vérifier que le contenu correspond

CIDv0 vs CIDv1

Propriété	CIDv0	CIDv1
Préfixe	Qm...	bafy... (dag-pb, répertoires et fichiers multi-chunks), bafk... (raw, contenu à bloc unique de petite taille), et d'autres selon le codec
Fonction de hachage	SHA-256 uniquement	Multiple (SHA-256, Blake2b, etc.)
Encodage	Base58 (casse mixte)	Multibase — base32 par défaut (minuscules, compatible DNS)
Auto-descriptif	Non	Oui (inclut les infos de codec + de hash)
Chunker	256 KiB par défaut (hérité)	1 MiB selon IPIP-0499
Encodage des feuilles	Encapsulé en dag-pb	Octets bruts (raw-leaves=true)

Ce qu'émet IPFS.NINJA

Les téléversements et épinglages effectués après le 13/07/2026 renvoient CIDv1 par défaut : encodage CIDv1 en base32, chunks de 1 MiB, feuilles brutes — le profil IPIP-0499 unixfs-v1-2025. Implications pratiques :

• Les petits fichiers (≤ 1 MiB) reviennent sous forme de bafk... (CIDv1 brut à bloc unique)
• Les fichiers volumineux et les répertoires reviennent sous forme de bafy... (CIDv1 dag-pb)
• Un fichier téléversé chez nous obtient le même CID que calculerait n'importe quel outil moderne (Helia, Kubo récent, ipfs-car) à partir des mêmes octets

Rétrocompatibilité

Les CID Qm... hérités des téléversements précédents restent entièrement résolubles — le gateway, POST /pin, GET /file/:cid, les résolveurs IPNS, et tous les autres endpoints acceptent les deux formats indéfiniment. Si vous avez un CID Qm... provenant d'un téléversement précédent, rien de ce que vous avez construit ne cesse de fonctionner.