Description
Checklist
- My issue is specific & actionable.
- I am not suggesting a protocol enhancement.
- I have searched on the issue tracker for my issue.
Description
Background
Newcomers to IPFS often face problems providing to the DHT. The most acute version of this problem is that beyond a certain threshold of CIDs to provide, the default Kubo configuration will simply not work and the node will not be able to make its CIDs discoverable.
To address these pains, there are ongoing efforts to improve the DHT implementation and how records are provided to the DHT.
This feature suggestion attempts to alleviate some of these pains with new self-service commands to provide more insight into the process and enable users to adjust their Kubo configuration based on the insights they observe.
Add LastRun
NextRun
to ipfs stats provide
The command currently outputs four fields:
TotalProvides: 58
AvgProvideDuration: 1.588721s
LastReprovideDuration: 42.698502s
LastReprovideBatchSize: 29
It would be useful to know when the last provide run was and when the next run will be. These could be named LastRun
and NextRun
(though these are just suggestions).
Another thing that would be helpful is to clarify the difference between TotalProvides
and LastReprovideBatchSize
in the usage.
Rename ipfs bitswap reprovide
to ipfs dht reprovide
Having the DHT provide command as a subcommand of bitswap
makes no sense. Moving it to be a subcommand of dht
, i.e. ipfs dht reprovide
would make more sense.