Decrease Time for Root CID Availability 10x on `ipfs add`

[dennis-tra]

Checklist

• My issue is specific & actionable.
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

Description

I'm suggesting to perform a single optimistic provide operation for the root CID when the user runs ipfs add, copies a CID from the Web UI or similar operations.

Right now, running ipfs add with 100MiB of random data takes ~0.5s until the command returns. However, it takes up to 30s until the root CID is available in the network on a clean install. If the provide queue is already populated it may take even longer until the CID is being provided (is that true or is the new root CID put at the beginning of the queue?).

Running a single optimistic provide operation just on the root CID (either sync to the ipfs add command or also async) will drastically improve the user experience because users can immediately (within 0.5s/2.5s in 50%/95% of the cases) act upon that CID (request it from the gateway, another kubo peer, etc.).

These were the performance differences when we measured this ~1.5-2y ago:

Caveat:

• the kubo node has to have a network size estimate which it will only get during the routing table bootstrap phase
• the current optimistic provider implementation applies the strategy globaly to the entire DHT instance. Single operation cannot be run optimistically in isolation as the code is written right now.

Context:

• Promoting Optimistic Provide from experimental to production ready #10047
• https://www.fiz-karlsruhe.de/sites/default/files/FIZ/Dokumente/Forschung/Mathematik/INFOCOM24-IPFS.pdf

[mishmosh]

This would be a very nice improvement to a kubo user's first impressions.

[lidel]

Triage notes:

• PoC would be ipfs add --fast-root-provide=true|false (enabled by default) that spawns an equivalent of one-time ipfs routing provide --recursive=false CID as async job
• but ideas welcome

[mishmosh]

Is the plan to make this a flaggable option first, then turn it on by default if it works well? If the goal is to improve first impressions for users with clean installs, they are unlikely to discover this option on their own; default would have a bigger impact.

Is --fast-provide too ambiguous?

[gammazero]

Yes, plan is to provide root CIDs by default, and have a flag to enable/disable (true by default). I agree that --fast-provide is not very clear. Open to suggestions if you have some.