Mga Content Identifier (CID)

Ang natatanging fingerprint na natatanggap ng bawat IPFS file.

Ano ang CID?

Ang Content Identifier (CID) ay isang self-describing na label na natatanging nagpapakilala sa isang piraso ng data sa IPFS. Nagmula ito sa cryptographic hash ng nilalaman ng file, kasama ang metadata tungkol sa hashing algorithm at encoding format na ginamit.

bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Ang mga CID na nagsisimula sa bafy (o bafk para sa maliit na single-block na nilalaman) ay gumagamit ng CIDv1, ang modernong self-describing na format. Ang legacy na mga CID na nagsisimula sa Qm ay gumagamit ng CIDv0 (base58-encoded SHA-256) — valid pa rin, resolvable pa rin, ngunit hindi na ito ang default na output para sa bagong nilalaman.

Mga pangunahing katangian

• Deterministic — Ang parehong file ay palaging gumagawa ng parehong CID. Mag-upload ng parehong imahe nang dalawang beses at makakakuha ka ng parehong identifier.
• Natatangi — Kahit isang byte na pagbabago ay gumagawa ng ganap na kaibang CID. Ginagawa nitong tamper-evident ang mga CID.
• Self-verifying — Sinumang makatanggap ng file ay maaaring i-recompute ang hash at kumpirmahing tumutugma ito sa CID na hiniling nila.
• Immutable — Ang CID ay palaging nakaturo sa parehong nilalaman. Hindi mo mababago kung ano ang nire-resolve ng CID.

Mga CID sa IPFS.NINJA

Bawat file na ina-upload mo ay nagbabalik ng CID sa API response. Gamitin ito para:

• I-access ang file sa pamamagitan ng gateway: ipfs.ninja/ipfs/<CID>
• Kunin ang file metadata: GET /file/<CID>
• I-reference ang nilalaman on-chain (mga NFT, smart contract)
• Ibahagi sa kahit sino — ma-verify nila na tumutugma ang nilalaman

CIDv0 vs CIDv1

Katangian	CIDv0	CIDv1
Prefix	Qm...	bafy... (dag-pb, mga directory at multi-chunk na file), bafk... (raw, maliit na single-block na nilalaman), at iba pa depende sa codec
Hash function	SHA-256 lang	Marami (SHA-256, Blake2b, atbp.)
Encoding	Base58 (mixed case)	Multibase — base32 bilang default (lowercase, DNS-safe)
Self-describing	Hindi	Oo (kasama ang codec + hash info)
Chunker	256 KiB legacy na default	1 MiB ayon sa IPIP-0499
Leaf encoding	Naka-wrap sa dag-pb	Raw bytes (raw-leaves=true)

Ano ang ini-emit ng IPFS.NINJA

Ang mga upload at pin na ginawa pagkatapos ng 2026-07-13 ay nagbabalik ng CIDv1 bilang default: CIDv1 base32 encoding, 1 MiB na chunks, raw leaves — ang IPIP-0499 unixfs-v1-2025 profile. Mga praktikal na implikasyon:

• Ang maliliit na file (≤ 1 MiB) ay babalik bilang bafk... (raw single-block CIDv1)
• Ang mas malalaking file at directory ay babalik bilang bafy... (dag-pb CIDv1)
• Ang file na na-upload sa amin ay makakakuha ng parehong CID na kakalkulahin ng anumang modernong tool (Helia, pinakabagong Kubo, ipfs-car) mula sa parehong bytes

Backward compatibility

Ang legacy Qm... na mga CID mula sa mga naunang upload ay nananatiling ganap na resolvable — tinatanggap ng gateway, POST /pin, GET /file/:cid, IPNS resolvers, at bawat ibang endpoint ang parehong format nang walang katapusan. Kung may Qm... na CID ka mula sa isang naunang upload, walang tumitigil sa paggana sa itinayo mo na.