Pinning integration: descope stats from Settings screen

[lidel]

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

[jacobheun]

@lidel while it's a very nice feature to have I agree we should not include it in the initial MVP work. It's not necessary for initial functionality and would be easy to add later without needing to change the existing spec.

[jessicaschilling]

+1, but let's be sure to consider thoroughly for post-MVP work.

[momack2]

I’d really like to keep this in scope if possible. It helps answer the question of “which pinning service am I using) without having to go check a bunch of different sites, which would be really annoying. If we need to replace - is there something we can replace it with to give that signal?

[jessicaschilling]

@momack2 Not suggesting to remove the rows themselves, rather just the "files" and "bandwidth used" columns.

[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.

[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.

[jessicaschilling]

@lidel Are we OK to close this issue now that we're proceeding with "pin count"?

[lidel]

Yes, I talked with @aschmahmann and iiuc we will have some type of stat command that returns the number of pins in each state (queued/pinning/pinned/failed)