Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

IPIP-49: CIDv2 “fat pointers” #49

Closed
wants to merge 1 commit into from
Closed

IPIP-49: CIDv2 “fat pointers” #49

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -113,6 +113,30 @@ See the section: [How does it work?](#how-does-it-work)
<cidv1> ::= <multibase-prefix><multicodec-cidv1><multicodec-content-type><multihash-content-address>
```

### CIDv2 ("Fat Pointers")

CIDv2 offers a way to encode context markers (signalling) into the IPLD link layer.

CIDv2 is used for describing both *data* and the *context* for that data. A specific definition of
context is not needed, as any context one would wish to signal in the link layer is effectively
supported.

CIDv2 is, quite literally, two CIDs.

```
<cidv2> ::= <data-cid><context-cid>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope with cid you mean how CIDs are used today and not what the spec says, i.e. these won't contain a multibase prefix.

```

CIDv2 *can* be used in a reverse compatible manor with CIDv1 as a codec, which allows for CIDv2
links to be encoded as separate hash addressed blocks or inlined into data structures with
and `identity` multihash as CIDv1. The requirements for different use cases will lead to different
encodings, and as support CIDv2 becomes more widespread we should expect more "native" use of CIDv2.

For instance, IPFS HTTP Gateways redirect to CID based subdomains which introduced a byte limit on the size
of the link. In this case, IPFS HTTP Gateways would create a single block for the CIDv2 link
with a 256b multihash encoded into CIDv1 for any redirect subdomain.
Comment on lines +135 to +137
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️
Just flagging this may not be the best example.
When subdomain gateways were created, we chose to not do this block generation because asking Gateways to create blocks on the fly is a can of worms (complexity, link rot):

  • what happens when I copy the CID created by the gateway and share it with someone? who is providing the root block now?
    • are gateways expected to cache/pin these artificial blocks and provide them to the network?
    • or is it to every IPFS client to double-publish both CIDs on the DHT?



## Decoding Algorithm

To decode a CID, follow the following algorithm:
Expand Down