Pinning integration: descope stats from Settings screen

Initial Settings mockups in WebUI include columns with basic stats: utilized storage as “Files” and “Bandwidth Used”:

Problem

Pinning Service API spec does not provide endpoint for reading this information.

Additionally, after sync with @jacobheun @aschmahmann and @alanshaw we decided to make API secrets write-only in go/js-ipfs config for security reasons. This means WebUI won’t be able to read API secret and make remote calls on its own.

Solutions

We have two ways of tackling this:

• weeks: add /stats endpoint to Pinning Service API and then support for it needs to land in go/js-ipfs and webui

or

• hours: descope this from MVP and remove “Files” and “Bandwidth Used” columns from Settings screen. User will still be able to check stats via three dot menu and a link to pinning service website.

Suggested solution

I don’t believe vaue added by those columns is worth additional complexity and additional work on Pinning Service and Core Impl. WG ends – are we ok with descoping them from MVP?

cc @jacobheun @jessicaschilling @rafaelramalho19 for quick temperature check, before I escalate this upstream

[jessicaschilling]

+1 for “pin count” being a good usage signal, at least for this version of the API. I suspect some others will emerge in time as more pinning services come on as adopters.

[lidel]

Context: we discussed this briefly during yesterday’s review call. My takeaway was we are ok with removing those specific storage/bandwidth stats, as long we replace them with something that provides “usage signal” to the user, like @momack2 said.

Potential candidate is “pin count” – number coud be read from count field returned by GET /pins?status=pinned in Pinning Service API (but we need to figure out how to expose this value over go-ipfs’ HTTP API).

Separately, we could discuss adding PinStatus.size field to indicate the size pinned DAG uses at the pinning service, but it brings similar question on how to expose it to WebUI from go-ipfs.

@jacobheun where should we track mapping from Pinning Service API to go-ipfs commands and HTTP API? Even a hackpad would help with resolving gaps like ones described above.