Better self-service commands for DHT providing

[2color]

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.

[Jorropo]

We deprecated most of ipfs dht in favor of ipfs routing because the DHT isn't the only routing system anymore.

[2color]

We deprecated most of ipfs dht in favor of ipfs routing because the DHT isn't the only routing system anymore.

Does Kubo support providing records to any other routing system? As far as I'm aware, the delegated routing API v1 doesn't specify how provider records are written.

[lidel]

Triage notes:

• adding features proposes here sounds useful
  • Add LastRun NextRun to ipfs stats provide
  • Rename ipfs bitswap reprovide to ipfs dht reprovide ipfs routing reprovide
    • check 💭 if we want to have PUT /routing/v1 (IPIP-378: Delegated Routing HTTP POST API specs#378), then it belong to routing and not dht namespace.
• good opportunity to cleanup ipfs dht (remove deprecated dht commands aliased to routing)
  • 💭 /api/v0/dht/* may be used by legacy delegated routing, but its been deprecated for a while, and removing it finally makes people switch to /routing/v1

[gsergey418alt]

Moved the reprovide command and added LastRun, NextRun stats. Boxo PR, Kubo PR

[guillaumemichel]

We are about to refactor the Provide Interface to allow providing to IPNI. (see announcement, under Improve the providing subsystem in Kubo).

LastRun and NextRun are DHT specific. We can ship this change for now, and we will need to refactor the ipfs stats provide section anyway once Kubo will be able to provide to IPNI.

Renaming ipfs bitswap reprovide to ipfs routing reprovide still seems accurate, but we may change the behaviour or remove altogether this command once the provide interface refactoring is shipped.

[guillaumemichel]

@2color is NextRun for the FullRT (Accelerated DHT client) only? IMO it makes sense to have such a metric only if CIDs are reprovided by batch all together.

AFAIU when using the normal DHT, CIDs individually reprovided after the ReprovideInterval. This implies that a host providing a fair number of records over time, will always have a reprovide scheduled a few minutes away for a single/few CIDs.

The same is true for LastRun, if the DHT is continually reproviding a few CIDs, this metric isn't very insightful.

[guillaumemichel]

Addressed in #10677