Pins missing in new 2.12 version

[kallisti5]

Describe the bug
The "pins" section is missing in the new 2.12.1 version. pins are also not visible.

To Reproduce

• You can navigate to /ipns/dev.webui.ipfs.io/#/files
  (it's empty even though I have things pinned)
• You can change the url to /ipns/dev.webui.ipfs.io/#/pins it works, but still no local pins show up.

Expected behavior
My local pins should show up.

Screenshots

Desktop:

• OS: Linux
• Browser: Firefox, Opera

Additional context
Multiple pins should exist.. but the webui is empty

[kallisti5]

IPFS Server is 0.8.0

[kallisti5]

Here's ipfs pin ls showing one or more pins...

/ # ipfs pin ls --stream                                                                                                       
QmdRetqMCSq2wfmmYVppMTSc754akwbV418CpXcR3y9PDC recursive         
.                                                              

[lidel]

(originally posted on matrix, reposting here for discoverability)

Files now show pin indicator column on Files screen.

The dedicated screen for listing low level local pins got removed from WebUI to reduce confusion, as low level pins were never designed to be exposed to GUI users, it is something you use on servers with huge datasets. Everything in MFS (Files) is already protected from local GC and enables you to assign human-readable names to CIDS, which is a better experience for Desktop/GUI users than a wall of nameless CIDs.

I personally have 1k of low level nameless pins, and it is impossible to make any meaningful decision as a desktop user by that point. I won't have time to inspect 1k of my local pins and decide which one I want to keep or not. I just keep them around at this point. But If I used MFS from the beginning, then I would have meaningful dir/filenames that would make cleanup easy.

That is why we v2.12 makes Files (MFS) the preferred way to keep things around by regular users, and will move more of our GUIs in that direction.

PS. ipfs pin ls lists all indirectly pinned blocks, that is too much.
What you want is to only list roots of recursive pins: ipfs pin ls --type=recursive

If you have some old local pins around and really want to manage them via Files screen, you can do one time import to MFS via this one-liner:

ipfs files mkdir /old_local_pins && for cid in $(ipfs pin ls --type=recursive -q); do ipfs files cp /ipfs/$cid /old_local_pins/$cid; done

[kallisti5]

Hm.. even if the focus is now MFS, it still should be possible to show purposeful information on locally pinned content.

Here's a use case:

I have two IPFS nodes under my control. One is serving content from MFS, the other pins that content via CID. I would need to set my new CID via ipfs files chcid to see it in the webui on my other node.

The webui doesn't show the "current CID" of MFS, and nodes can diverge from the same MFS filesystem.
(Set MFS CIDA on both nodes)

• Node A adds files, Node B never sees the new files.
• Node B adds other files, Node A never sees those changes as the CID's have diverged

If you have a solid understanding of IPFS and MFS, this makes sense. If you're an end user (who will most likely be looking at the webui), this is all really confusing and "nothing shows up"

These are all really "big issues" to be honest, likely beyond this bug ticket.

[lidel]

Yeah, if you can flesh out an actionable feature that could be added, (eg. showing the root CID of MFS, patters for sync between nodes etc), please fill in a new issue 👍

FYSA, we now have remote pinning via MFS repin policy in go-ipfs 0.8.0. It makes it easier for people to set up automatic, one-way backup to some service. Webui v2.12.x provides a simple GUI for enabling remote pinning of the MFS root CID:

This is a GUI for Pinning.RemoteServices..Policies.MFS.Enable. When enabled, IPFS node will periodically update the remote pin for MFS root, removing the need for manually pinning individual files.

[NatoBoram]

I personally have 1k of low level nameless pins, and it is impossible to make any meaningful decision as a desktop user by that point. I won't have time to inspect 1k of my local pins and decide which one I want to keep or not. I just keep them around at this point.

Have you considered that some other users might be "not you" and might need this feature so it's easier to sort through their 50 pins and move them to the MFS / remove them?

[kallisti5]

Have you considered that some other users might be "not you" and might need this feature so it's easier to sort through their 50 pins and move them to the MFS / remove them?

I have this same issue. Even as "extremely technical" user the IPFS webui is unclear and complicated. The pinning concept was easy to understand, but now nothing aligns in the webui. (Space consumed vs MFS)

I really wasn't really able to "figure out" IPFS until I stopped trying to use the webui. Concepts aren't named inline with official naming... so users won't equate "my files" to MFS.

[lidel]

@NatoBoram yes, that is why you can still open #/pins or (preferably) do one-time import using the script from #1773 (comment) and do sorting manually.

@kallisti5 Indeed. the naming is confusing even in the CLI ( we have ipfs files and not ipfs mfs, but https://proto.school/course/ipfs covers "Mutable File System" and "Regular Files API"). If you have ideas how we could clarify naming around MFS, please fill a new issue, so it is not lost.

[LucSalommez]

Hello, I just want to share my feedback as well.
I use a distant node to store files programmatically (sent by my computer for exemple).

It is a lot easier for me to check the state of my IPFS node and to manage it through the webui.
This is why I connect to the webui of my distant node and want to be able to remove files and pins from there.

On my local dev tests, I use http://127.0.0.1:5001/ipfs/bafybeif4zkmu7qdhkpf3pnhwxipylqleof7rl6ojbe7mq3fzogz6m4xk3i/#/files

Where I have all my pins available from a section displayed in the UI.
When using the WebUI of my distant node however, the feature is removed.
My pins are inaccessible from the UI.

This feature is in my opinion very useful to a lot of people and removing it does not make the tool any more accessible, quite the opposite actually.

Without @kallisti5 complaining and @lidel 's answer I would have never known I can still access this page using #/pins.
Having to come up to this place and read every comment to find a way is pretty tricky to say the least.

Can you consider making pins accessible on the UI again please ?