Add migration for IPNS record move

[Stebalien]

see: ipfs/kubo#5007

@whyrusleeping am I doing this right?

• make sure this still builds with distributions. May need to do something to ensure we have gx available (as I've introduced it as a dep).

[whyrusleeping]

you comitted a binary

[whyrusleeping]

gotta knock it off with that git add . nonsense, git add -u is far superior

[whyrusleeping]

i'd say its probably worth comitting the gx vendored deps in this case, just to make this easily go-gettable

[Stebalien]

i'd say its probably worth comitting the gx vendored deps in this case, just to make this easily go-gettable

I can, it's just a lot of code as I currently depend on the go-ipfs repo. I can look into removing unused packages again, we'll see where that goes.

[Stebalien]

So, I was able to do a selective vendor (only used packages):

> go list -json -f '{{.Deps}}' | jq -r '.Deps[] | select(startswith("gx/"))' | while read pkg; do mkdir -p "vendor/$pkg" && cp $GOPATH/src/$pkg/*.{s,go}(N) "vendor/$pkg"; done

[Stebalien]

gotta knock it off with that git add . nonsense, git add -u is far superior

Unless you're adding a bunch of new files (e.g., git add . to add a new directory). I really need to add a git commit hook that catches binary files.

[Stebalien]

@whyrusleeping all vendored and passing tests.

Should I unvendor iptb and fetch from dists? I vendored the code as it uses gx but even after stripping unnecessary packages, it's still large.

[Stebalien]

• update distributions.

[kevina]

Note, I am going to want to also migrate the repo to check for blocks with an insecure has in the repo and also remove any instanced of blocks with an id hash as they should not be stored before a new go-ipfs version is released.

Ref:ipfs/kubo#4766

[kevina]

@Stebalien

Unless you're adding a bunch of new files (e.g., git add . to add a new directory). I really need to add a git commit hook that catches binary files.

"git gui" is really good for this. That is what I tend to use, you can then easily hand pick the correct files.

[Stebalien]

Note, I am going to want to also migrate the repo to check for blocks with an insecure has in the repo and also remove any instanced of blocks with an id hash as they should not be stored before a new go-ipfs version is released.

I assume this will be a separate migration, right?

"git gui" is really good for this. That is what I tend to use, you can then easily hand pick the correct files.

I can do that on the command line as well (faster than opening a program, usually). I just get lazy.

[kevina]

I assume this will be a separate migration, right?

I'm not sure yet. That would seam to be the easiest think to do. I am not sure (but have not looked closely yet) if it is possible to do two migrations at once in a single version bump.

[Stebalien]

@kevina we'd have two separate repo versions but they'd be run at the same time (the repo version really just counts the number of migrations we've applied). I'd rather avoid adding anything to this current set of PRs as it's blocking everything and already contains a ton of changes (it'll also bring in some new datastore changes, logging changes, several libp2p fixes, etc.).

[kevina]

@Stebalien okay them, I like the idea of two separate migrations to avoid complications, I just don't want the user to have to migrate twice when upgrading to a new release version.

It was @whyrusleeping idea to possible combine them.

[whyrusleeping]

it does feel a bit odd to be using private keys here instead of just public keys, but its not a huge deal i guess

[Stebalien]

Yeah... but that's what the Keystore/Identity gives me.

Given that I've already built the dist (and linked to it from go-ipfs), I'll leave this as-is unless I have to make other changes.

[whyrusleeping]

so this is only migrating the ipns entries, and not any of the other things the DHT writes, correct?

[Stebalien]

Yep.

[whyrusleeping]

migration seems pretty simple, only one weird bit around using private keys where we technically only need public keys, but its not actually that big of a deal.