You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of p.r. #5285go-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.
The text was updated successfully, but these errors were encountered:
@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.
@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.
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.
The text was updated successfully, but these errors were encountered: