Push CID to DHT when publishing a name

[RubenKelevra]

I investigated a bit a performance issue - where it takes quite a long time before data behind an IPNS record can be resolved via the DHT.

It seems that the newly added content is too large, so there's a large backlog of newly added pins and MFS data on the node, that it is able to push the CID for the name record in a reasonable amount of time.

A dedicated ipfs dht provide <CID> before running ipfs name publish --key=<keyID> <CID> solved this issue for me.

So there seems to be an improvement opportunity:

If the CID which should be published as a name record is still somewhere on the queue for sending it to the DHT as provider IPFS could give this CID priority, that it will be the next CID to be published. This way ipfs makes rue that the new name record will be resolvable via DHT.

[Stebalien]

This is a great idea.

[Stebalien]

I'd modify the Publish function in core/coreapi/name.go to concurrently send a provider record to the DHT.

[RubenKelevra]

I'd modify the Publish function in core/coreapi/name.go to concurrently send a provider record to the DHT.

Yeah, this probably works too, if the queue is not easily accessible from this context without having to lock it completely.

But this of course will lead to a double provide by the client. Depending on the amount of IPNS updates.

[Stebalien]

We do put the root of objects into a queue to provide after we finish adding. However, I'm guessing this may be backed up.

Providing while publishing an IPNS record is a bit expensive, but publishing an IPNS record is expensive enough that it's not a huge issue.