Ідентифікатори контенту (CID)

Унікальний відбиток, який отримує кожен файл IPFS.

Що таке CID?

Content Identifier (CID) — це самоописуючий ідентифікатор, який однозначно ідентифікує дані на IPFS. Він отримується з криптографічного хешу вмісту файлу, поєднаного з метаданими про використаний алгоритм хешування та формат кодування.

bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

CID, що починаються з bafy (або bafk для малого одноблокового контенту), використовують CIDv1 — сучасний самоописуючий формат. Застарілі CID, що починаються з Qm, використовують CIDv0 (base58-кодований SHA-256) — все ще дійсний, все ще розв'язуваний, але більше не вихідний формат за замовчуванням для нового контенту.

Ключові властивості

• Детерміністичний — Той самий файл завжди дає той самий CID. Завантажте одне й те саме зображення двічі — і отримаєте однаковий ідентифікатор.
• Унікальний — Навіть зміна одного байта створює зовсім інший CID. Це робить CID стійкими до підробки (tamper-evident).
• Самоперевірний — Будь-хто, хто отримує файл, може перерахувати хеш і підтвердити, що він відповідає запитаному CID.
• Незмінний — CID завжди вказує на той самий контент. Ви не можете змінити, на що розв'язується CID.

CID в IPFS.NINJA

Кожен файл, який ви завантажуєте, повертає CID у відповіді API. Використовуйте його для:

• Доступу до файлу через gateway: ipfs.ninja/ipfs/<CID>
• Отримання метаданих файлу: GET /file/<CID>
• Посилання на контент on-chain (NFT, смарт-контракти)
• Поширення будь-кому — вони можуть перевірити відповідність контенту

CIDv0 проти CIDv1

Властивість	CIDv0	CIDv1
Префікс	Qm...	bafy... (dag-pb, директорії та багатоблокові файли), bafk... (raw, малий одноблоковий контент), а також інші залежно від кодека
Хеш-функція	Тільки SHA-256	Декілька (SHA-256, Blake2b тощо)
Кодування	Base58 (змішаний регістр)	Multibase — base32 за замовчуванням (нижній регістр, безпечний для DNS)
Самоописуючий	Ні	Так (включає інформацію про кодек і хеш)
Чанкер	Застарілий за замовчуванням 256 KiB	1 MiB відповідно до IPIP-0499
Кодування листків	Обгорнуте в dag-pb	Сирі байти (raw-leaves=true)

Що видає IPFS.NINJA

Завантаження та піни, зроблені після 2026-07-13, за замовчуванням повертають CIDv1: base32-кодування CIDv1, блоки по 1 MiB, raw leaves — профіль IPIP-0499 unixfs-v1-2025. Практичні наслідки:

• Малі файли (≤ 1 MiB) повертаються як bafk... (raw одноблоковий CIDv1)
• Більші файли та директорії повертаються як bafy... (dag-pb CIDv1)
• Файл, завантажений через нас, отримує той самий CID, який обчислив би будь-який сучасний інструмент (Helia, найновіший Kubo, ipfs-car) з тих самих байтів

Зворотна сумісність

Застарілі CID Qm... з попередніх завантажень залишаються повністю розв'язуваними — gateway, POST /pin, GET /file/:cid, резолвери IPNS та кожен інший ендпоінт приймають обидва формати необмежено довго. Якщо у вас є CID Qm... з попереднього завантаження, ніщо з того, що ви побудували, не перестає працювати.