Pinning integration [SPIKE]: Determine how/where files are pinned

[jessicaschilling]

Note: This issue is part of a larger pinning service integration epic undertaken spring/summer 2020.

In brief

Research, discuss, and come to conclusions regarding how we can actually implement the Files screen pinning features originally specified, vis-a-vis distinguishing between pins on multiple services and/or the local node. These decisions will likely need to take place before we go too far down the road of architecting the API.

• How do we determine where (on which services) a particular file is pinned for purposes of displaying on the Files screen?
• How does this actually manifest itself in terms of when/how often we query for that info?
• ... and other questions TBD

[lidel]

We discussed this a bit and the underlying insight here is that below user flows need to work:

• user configures services in ipfs-desktop → same should show in webui at http://127.0.0.1:5001/webui AND latest version at https://webui.ipfs.io opened with Companion
• user cloud-pins a file in ipfs-desktop → same should show at https://webui.ipfs.io
• pinning service should work even when webui is closed, and user adds a new local pin or new files to MFS via ipfs CLI or from IPFS companion
  • without this, we will have extremely confusing user experience and bogus bug reports

We can't store pinning service info in local storage, as its not persisted across origins and browsers. Everything in webui depends on HTTP API.

This suggests that go-ipfs needs to expose additional APIs for managing pinning services.
We need persistence at the level of go-ipfs.

Settings screen needs

We need to be able to persist pinning service details using HTTP API:

ipfs pin service add    [name, api url, api key, type]
ipfs pin service rm     [name]
ipfs pin service update [name, api url, api key, type]
ipfs pin service ls     [name, api url, type, stats]

Note: when service is added with type=pins or type=all-in-mfs, go-ipfs will take care of automatically calling the service API URL with CID of pinned files.

Files screen needs

Assume files screen opens a directory with 100 files.
If we want to display cloud-pin status for each, we need to ask remote service for status of CID of each file somehow.

How to do this is unclear yet: should go-ipfs act as a proxy, or should webui take remote API url returned by ipfs pin service ls and make checks on its own?

Either way, the called API needs to accept a list of CIDs and return status for each, in the same order.

Alternative: do not provide any cloud-pin indicator or status on Files screen at all.

[Stebalien]

We need to be able to persist pinning service details using HTTP API:

Can you update the config directly?

[lidel]

@Stebalien ah, yes, we do. Are you suggesting we simply add it to the config?
That would be enough for us I believe (no need for new command), and would open door for go-ipfs to use that data in the future.

Note to self: for MVP we could open a PR against https://github.com/ipfs/go-ipfs-config/ with what we need to persist.