Update ipns validator

[dirkmc]

Update go-ipfs to use new validation function format in go-libp2p-record
#4566 was getting messy so I closed and opened this new PR

[vyzo]

do we need this split?

[dirkmc]

You're right the relative path component of the IPNS path is not stored in the DHT (only in DNS)

[vyzo]

You need to add the new dependencies to package.json using gx update.

[vyzo]

you also need to go fmt -- codeclimate rightfully complains.

[dirkmc]

I wanted to ask you guys about the dependencies. I used gx update to update the go-libp2p-record dependency across the project, and it warned me that I would also need to update go-libp2p-kad-dht, but when I did that it broke a lot of things because of mismatches between the library versions that the new go-libp2p-kad-dht lib imports vs the library versions this project imports.

Is there some easy way of doing all this package management stuff so it will figure out what needs to be updated and do it one step?

[vyzo]

Sounds like some dependency will need to propagage -- @Stebalien usually handles those.

[whyrusleeping]

We need to at some point write a guide for "propogating gx dependencies"

[dirkmc]

The gold standard is whether a recovering java dev can understand it

[Stebalien]

@dirkmc Actually, gx is very Java-esque in it's paranoia. But yes, this is blocked on the cmds PR #4568.

[Stebalien]

LGTM. We'll have to hold for the cmds merge.

[Stebalien]

Do we actually need to call string here?

[dirkmc]

No, we should be able to get rid of that cast once the go-libp2p-peer lib is updated

[Stebalien]

Got it.

[dirkmc]

Once the cmds merge is complete I will update the deps and test manually

[Stebalien]

So, unfortunately, this actually breaks things (the republisher test cases) because we allow publishing IPNS records using one key and then signing the DHT record with another. For example, when publishing an IPNS record with an alternative key, we sign it with the alternative key and then sign the DHT record with the peer key.

The correct solution here is to:

1. Get rid of the DHT signature/author field. We can actually do this without breaking anything.
2. Validate the IPNS (not DHT) signature in the validator.

Unfortunately, validating the IPNS signature in the validator is a bit tricky... so I'm not going to fix that in my existing pr (#4610).

[dirkmc]

That makes sense, if there's a peer ID in the key there's no need to replicate it in the DHT record.
So are you imagining that the DHT would create a map[peer.ID]PubKey from the peer store and pass that to the validator function?

[Stebalien]

So are you imagining that the DHT would create a map[peer.ID]PubKey from the peer store and pass that to the validator function?

No, we'll probably construct the IPNS validator as a closure and have it capture the peerstore (so it can extract the keys from that).

Ideally, the validator would take some additional "validation" information but we'll probably need to wait for a general-purpose IPRS for that.

[dirkmc]

Makes sense. Should we close this PR now that it's superseded by #4613?

[Stebalien]

Yes.