CID (Content IDentifier) Specification

Self-describing content-addressed identifiers for distributed systems

Table of Contents

• Motivation
• What is it?
• How does it work?
• Design Considerations
• Human Readable CIDs
• Versions
  • CIDv0
  • CIDv1
• Decoding Algorithm
• Implementations
• FAQ
• Maintainers
• Contribute
• License

Motivation

CID is a format for referencing content in distributed information systems, like IPFS. It leverages content addressing, cryptographic hashing, and self-describing formats. It is the core identifier used by IPFS and IPLD. It uses a multicodec to indicate its version, making it fully self describing.

You can read an in-depth discussion on why this format was needed in IPFS here: ipfs/specs#130 (first post reproduced here)

What is it?

A CID is a self-describing content-addressed identifier. It uses cryptographic hashes to achieve content addressing. It uses several multiformats to achieve flexible self-description, namely multihash for hashes, multicodec for data content types, and multibase to encode the CID itself into strings.

Concretely, a CIDv1 is a typed content address: a tuple of (content-type, content-address).

There is also CIDv2, which extends CIDv1 to allow you to add additional metadata to a content-address: (content-type, content-address, metadata-type, metadata-address)

How does it work?

Current versions: CIDv1, CIDv2

A CIDv1 has four parts:

<cidv1> ::= <mb><multicodec-cidv1><mc><mh>
# or, expanded:
<cidv1> ::= <multibase-prefix><multicodec-cidv1><multicodec-content-type><multihash-content-address>

Where

• <multibase-prefix> is a multibase code (1 or 2 bytes), to ease encoding CIDs into various bases. NOTE: Binary (not text-based) protocols and formats may omit the multibase prefix when the encoding is unambiguous.
• <multicodec-cidv1> is a multicodec representing the version of CID, here for upgradability purposes.
• <multicodec-content-type> is a multicodec code representing the content type or format of the data being addressed.
• <multihash-content-address> is a multihash value, representing the cryptographic hash of the content being addressed. Multihash enables CIDs to use many different cryptographic hash function, for upgradability and protocol agility purposes.

That's it!

A CIDv2 is an extension of CIDv1, which adds an additional multicodec content-type and multihash content-address for metadata.

<cidv2> ::=
<mb><multicodec-cidv2><data-multicodec-content-type><data-multihash-content-address><metadata-multicodec-content-type><metadata-multihash-content-address>

This can be used, for example, to combine a pointer to an IPLD data value, with its corresponding IPLD Schema.

Design Considerations

CIDs design takes into account many difficult tradeoffs encountered while building IPFS. These are mostly coming from the multiformats project.

• Compactness: CIDs are binary in nature to ensure these are as compact as possible, as they're meant to be part of longer path identifiers or URIs.
• Transport friendliness (or "copy-pastability"): CIDs are encoded with multibase to allow choosing the best base for transporting. For example, CIDs can be encoded into base58btc to yield shorter and easily-copy-pastable hashes.
• Versatility: CIDs are meant to be able to represent values of any format with any cryptographic hash.
• Avoid Lock-in: CIDs prevent lock-in to old, potentially-outdated decisions.
• Upgradability: CIDs encode a version to ensure the CID format itself can evolve.

Human Readable CIDs

It is advantageous to have a human readable description of a CID, solely for the purposes of debugging and explanation. We can easily transform a CID to a "Human Readable CID" as follows:

<hr-cid> ::= <hr-mbc> "-" <hr-cid-mc> "-" <hr-mc> "-" <hr-mh>

Where each sub-component is represented with its own human-readable form:

• <hr-mbc> is a human-readable multibase code (eg base58btc)
• <hr-cid-mc> is the string cidv# (eg cidv1 or cidv2)
• <hr-mc> is a human-readable multicodec code (eg cbor)
• <hr-mh> is a human-readable multihash (eg sha2-256-256-abcdef0123456789...)

For example:

# example CID
zb2rhe5P4gXftAwvA4eXQ5HJwsER2owDyS9sKaQRRVQPn93bA
# corresponding human readable CID
base58btc - cidv1 - raw - sha2-256-256-6e6ff7950a36187a801613426e858dce686cd7d7e3c0fc42ee0330072d245c95

See: https://cid.ipfs.io/#zb2rhe5P4gXftAwvA4eXQ5HJwsER2owDyS9sKaQRRVQPn93bA

# example CIDv2
bajkreib2n2yhsdzzvsd4stzyk2zn2lc5cehgqelaejq2tkjd2o5shloiw5kreihkhplt4k2qnyafe4rswpwxipagnwudvdrqm33cu4phl243jkq5wy
# corresponding human readable CID
base32lower - cidv2 - raw - sha2-256-256-f3a6eb0790f39ac87c94f3856b2dd2c5d110e6811602261a9a923d3bb23adc8b7 - raw - sha2-256-256-fea3bd73e2b506e00527232b3ed743c066da83a8e3066f62a71e75eb9b4aa1db6

Versions

CIDv0

CIDv0 is a backwards-compatible version, where:

• the multibase of the string representation is always base58btc and implicit (not written)
• the multicodec is always dag-pb and implicit (not written)
• the cid-version is always cidv0 and implicit (not written)
• the multihash is written as is but is always a full (length 32) sha256 hash.

cidv0 ::= <multihash-content-address>

CIDv1

See the section: How does it work?

<cidv1> ::= <multibase-prefix><multicodec-cidv1><multicodec-content-type><multihash-content-address>

CIDv2

<cidv2> ::= <mb><multicodec-cidv2><data-multicodec-content-type><data-multihash-content-address><metadata-multicodec-content-type><metadata-multihash-content-address>

Decoding Algorithm

To decode a CID, follow the following algorithm:

1. If it's a string (ASCII/UTF-8):

• If it is 46 characters long and starts with Qm..., it's a CIDv0. Decode it as base58btc and continue to step 2.
• Otherwise, decode it according to the multibase spec and:
  • If the first decoded byte is 0x12, return an error. CIDv0 CIDs may not be multibase encoded and there will be no CIDv18 (0x12 = 18) to prevent ambiguity with decoded CIDv0s.
  • Otherwise, you now have a binary CID. Continue to step 2.

2. Given a (binary) CID (cid):
   • If it's 34 bytes long with the leading bytes [0x12, 0x20, ...], it's a CIDv0.
     • The CID's multihash is cid.
     • The CID's multicodec is DagProtobuf
     • The CID's version is 0.
   • Otherwise, let N be the first varint in cid. This is the CID's version.
     • If N == 0x01 (CIDv1):
       • The CID's multicodec is the second varint in cid
       • The CID's multihash is the rest of the cid (after the second varint).
       • The CID's version is 1.
     • If N == 0x02 (CIDv2):
       • The CID's data-multicodec is the second varint in cid
       • The CID's data-multihash-multicodec is the third varint in cid
       • The CID's data-multihash-size is the fourth varint in cid
       • The CID's data-multihash-digest is the next number of bytes indicated by the data-multihash-size
       • The CID's metadata-multicodec is a varint in cid immediately following the data-multihash-digest
       • The CID's metadata-multihash is the rest of the cid (after the metadata-multicodec).
       • The CID's version is 2
     • If N == 0x03 (CIDv3), the CID version is reserved.
     • If N is equal to some other multicodec, the CID is malformed.

Implementations

• go-cid
• java-cid
• js-cid
• rust-cid
• py-cid
• elixir-cid
• Add yours today!

FAQ

Q. I have questions on multicodec, multibase, or multihash.

Please check their repositories: multicodec, multibase, multihash.

Q. Why does CID exist?

We were using base58btc encoded multihashes in IPFS, and then we needed to switch formats to IPLD. We struggled with lots of problems of addressing data with different formats until we created CIDs. You can read the history of this format here: ipfs/specs#130

Q. Is the use of multicodec similar to file extensions?

Yes, kind of! like a file extension, the multicodec identifier establishes the format of the data. Unlike file extensions, these are in the middle of the identifier and not meant to be changed by users. There is also a short table of supported formats.

Q. What formats (multicodec codes) does CID support?

We are figuring this out at this time. It will likely be a table of formats for secure distributed systems. So far, we want to address: IPFS's original protobuf format, the new IPLD CBOR format, git, bitcoin, and ethereum objects.

Q. What is the process for updating CID specification (e.g., adding a new version)?

CIDs are a well established standard. IPFS uses CIDs for content-addressing and IPNS. Making changes to such key protocol requires a careful review which should include feedback from implementers and stakeholders across ecosystem.

Due to this, changes to CID specification MUST be submitted as an improvement proposal to ipfs/specs repository (PR with IPIP document), and follow the IPIP process described there.

Maintainers

Captain: @jbenet.

Contribute

Contributions welcome. Please check out the issues.

Check out our contributing document for more information on how we work, and about contributing in general. Please be aware that all interactions related to IPLD are subject to the IPFS Code of Conduct.

Small note: If editing the README, please conform to the standard-readme specification.

License

This repository is only for documents. These are licensed under a CC-BY 3.0 Unported License © 2016 Protocol Labs Inc.