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

Add flag to switch over to using CIDv1 #3243

Open
whyrusleeping opened this issue Sep 20, 2016 · 6 comments
Open

Add flag to switch over to using CIDv1 #3243

whyrusleeping opened this issue Sep 20, 2016 · 6 comments
Labels

Comments

@whyrusleeping
Copy link
Member

To make it the switch over easier, lets get an option in as soon as possible to make go-ipfs use and generate version 1 CIDs for all internally created data. This will still be using the existing protobuf encoding for everything, the only difference will be that instead of a bare multihash (CIDv0) being used to address blocks and dags, we will use a full CID

@whyrusleeping whyrusleeping added the help wanted Seeking public contribution on this issue label Sep 20, 2016
@whyrusleeping whyrusleeping added this to the ipld integration milestone Sep 20, 2016
@flyingzumwalt flyingzumwalt added the status/deferred Conscious decision to pause or backlog label Sep 26, 2016
@whyrusleeping whyrusleeping added the status/ready Ready to be worked label Dec 7, 2016
@whyrusleeping whyrusleeping modified the milestones: Ipfs 0.4.8, Ipfs 0.4.7 Mar 10, 2017
@whyrusleeping whyrusleeping modified the milestones: Ipfs 0.4.9, Ipfs 0.4.8 Mar 25, 2017
@whyrusleeping
Copy link
Member Author

@kevina this is done, yeah?

@kevina
Copy link
Contributor

kevina commented May 2, 2017

@whyrusleeping Depends on your definition of done. The merged p.r., #3743, only adds CidV1 support to the add command, other commands might need it and I also think it should be a global option not one local to add.

@whyrusleeping
Copy link
Member Author

@kevina fair enough, lets keep this one open.

@whyrusleeping whyrusleeping modified the milestones: Ipfs 0.4.10, Ipfs 0.4.9 May 8, 2017
@magik6k magik6k modified the milestones: Ipfs 0.4.10, Ipfs 0.4.11 Jul 28, 2017
@Kubuxu Kubuxu modified the milestones: Ipfs 0.4.12, go-ipfs 0.4.13 Nov 6, 2017
@Stebalien Stebalien removed the status/ready Ready to be worked label Dec 18, 2018
@nitishm
Copy link

nitishm commented Dec 18, 2018

I am interested in helping with this. How can I get a list of command that might need this option ?

@Stebalien Stebalien added status/in-progress In progress and removed help wanted Seeking public contribution on this issue labels Dec 18, 2018
@Stebalien Stebalien removed the status/deferred Conscious decision to pause or backlog label Dec 18, 2018
@Stebalien
Copy link
Member

This is a very involved issue that @kevina is currently working on. It looks deceptively simple but it's hard to do this without breaking things.

I've updated the labels to indicate the current status. Sorry for the confusion.

@kevina
Copy link
Contributor

kevina commented Dec 19, 2018

Yeah. My current things is we should do this via a config option. Switching to CIDV1 will break tones of stuff as we just expect a Cidv0 in many places, for example gx. Then we also need to go through and fix all the test cases which is fairly labor intensive, plus I am sure we will keep finding lingering bugs for months to years to come if we just switch everything to CIDv1.

The switch to base32 will likely come first. This switch will convert CIDv0 to CIDv1 for display, but the internal links in a dag will still be CIDv0. This will break less as we have hacks in place already to look up CIDs by both CID versions and also CIDs can be converted back to Version 0 when required.

The switch to CIDv1 should come later. My thinking is provide a config and default it to CIDv1. This config option will effect most commands but not really low-level stuff so this should break less.

This still needs a lot of thought though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants