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.

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

RFC: Handling of CidV1/V0 at the bitswap level #5378

Open
kevina opened this issue Aug 13, 2018 · 3 comments
Open

RFC: Handling of CidV1/V0 at the bitswap level #5378

kevina opened this issue Aug 13, 2018 · 3 comments
Labels
topic/cidv1b32 Topic cidv1b32

Comments

@kevina
Copy link
Contributor

kevina commented Aug 13, 2018

As of p.r. #5285 go-ipfs will be able to return a block regardless of it if is given in CidV0 or CidV1. Soon, we will switch the blockstore to work with multihashes instead of CIDs.

However, for a period of time there will still be nodes that work at the CID level instead of the multihash level. These older nodes are very likely to have most of there content is CidV0. This can create a small problem when we start switch to CIDv1 at the UX level. For example, if there is some content that was originally available at CidV0, but we display it to the user as a Base32 CidV1 and the user then copy and pastes the link and tries to retrieve it, they may not be able to retrieve the content if the only nodes that have it are the older nodes.

My question is, do we want to try to solve this at the bitswap level? What I am thinking is that bitswap firsts tries to get the content using the original CID version (in the above example CIDv1), then after a brief timeout (maybe 5 seconds) it also requests the CIDv0 version of the hash. Once it retrieves either version it cancels both requests (if that is possible).

@Stebalien @whyrusleeping thoughts? I don't know enough about bitswap yet to really give any meaningful solutions.

@kevina kevina added the topic/cidv1b32 Topic cidv1b32 label Aug 13, 2018
@burdakovd
Copy link

One option is to internally query content in CIDv0 always (assuming old nodes keep content in CIDv0, and new nodes can handle both types of queries).

Then some time later - when most of the nodes update their software and can handle both types of queries, start querying directly in CIDv1.

@kevina
Copy link
Contributor Author

kevina commented Sep 4, 2018

@burdakovd Unfortunately old nodes may still have content in CIDv1, so we really need to try both CIDv0 and CIDv1 to be sure content doesn't become unavailable.

@kevina
Copy link
Contributor Author

kevina commented Oct 11, 2018

@Stebalien @diasdavid If I understood the discussion today the solution to this was to determine if the node we are talking supports retrieving the block regardless of the CID version. If the node does not as a temporary measure we will simply request both the blocking using both CIDv0 and CIDv1. This is dependent on the IPFS reporting the exact version. I need to verify that is the case.

@momack2 momack2 added this to Inbox in ipfs/go-ipfs May 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/cidv1b32 Topic cidv1b32
Projects
No open projects
Development

No branches or pull requests

2 participants