dir-index-html: add indicator if CID is cached in local datastore

[kallisti5]

Is your feature request related to a problem? Please describe.

As a user of IPFS, it's difficult to visualize if files are cached on the gateway you're connected to vs if the files need to be retrieved from the network.

Describe the solution you'd like
An indicator to show if a CID is cached on the current gateway.

Example (horrible) mock up:

The first three entries are cached on the gateway, the final one would require pulling from other IPFS nodes. Three indicators may be needed:

• Fully cached locally
• Partially cached locally
• Not cached locally

[lidel]

This is a sensible request.

• To avoid visual noise we should assume everything to be locally available, and display indicator only for content that is not 100% local
• TBD: not sure how expensive is to run ipfs files stat --with-local for every item. If it is too expensive, we could go with inexpensive check, perhaps ipfs dag stat --offline? (error means DAG is not 100% local)

[kallisti5]

seems fair. It would also help with the "pinned content visibility" issues found in other issues. It's a bit spread out, but would be a workaround for those.

Also, yeah.. it does sound potentially a bit expensive... so some care would be needed. If it was too expensive theoretically it could be used as an abuse mechanism (hammering a gateway for the availability of a complex recursive CID)

[xrazis]

If i understand correctly this issue does not belong in this repository, the changes need to happen to:

• The template file over at /ipfs/dir-index-html
• A couple of files regarding the geteway over at /ipfs/go-ipfs

I would love to take a look at it!

[lidel]

I am moving this issue to go-ipfs repo.

Caveat: generating static HTML is expensive, and we want to cache it for as long as possible, have per-release static Etag for these dir listings, so showing this via rendered HTML is not feasible – these status indicators will get out of sync pretty fast due to older version being read from cache.

If you are interested in moving this forward I'd look at #8783
This JS check will remove the need for re-generating entire HTML all the time.

If we have it, then static HTML page for dir listing could do JS fetch HEAD request for the each dir child in the viewport by sending request for it (e.g. with Accept: application/vnd.ipfs.cache.local content type).
This will work nicely with big directories – we should only fetch the state of visible items.

[xrazis]

@lidel i have a couple of questions before i open a PR. You can see my changes here.

• In the Javascript file I chose to pass the Listing.Path from the template rather than picking it up from the DOM. If that is undesirable i can switch it.
• What should the visual be like? Is there a set of icons that i can use or should I improvise? The ones in the icons.css do not have one that fit this case. I've put the letter R (from remote) just to demonstrate its functionality.

[lidel]

@xrazis thank you for poking at this! Feel free to open a PR, we can continue there, but for now quick feedback here:

• using .Listing from template is good.
  • nit: not every client will have JS enabled, mind changing JS code so <div> is appended to the <td> by JS, and not rendered by the HTML template for every item?
• afraid we only have these ipfs-webui icons here – I'd say improvise for now. R is fine as a placeholder. If we get blocked by this, we can fill a request to a design shop at Protocol Labs when we have the code working.