Ipfs-webui: Show pins, add pins and browse the whole universe

[hacdias]

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

No

Describe the solution you'd like

It would be interesting if we could show the user pinned pins (yeah!) on the Files section inside the Web UI. I imagine it as special folder with different icon and some explanation.

It'd be a read-only folder and would only be shown to users that have one or more recursive (and direct?) pins. The folder would allow to navigate the pinned directories/files.

It wouldn't, of course, show indirect pins.

Describe alternatives you've considered

Use the CLI. I'm thinking about something visual.

Additional context

N/A

---

Closes https://github.com/ipfs-shipyard/ipfs-desktop/issues/922.

[olizilla]

Yes, I want to show a page above the MFS root, that lists out yout pins, and some interesting CIDs, so you can see things in the blockstore that aren't in the MFS, and parhaps a way to ipfs.get an arbitrary CID.

[lidel]

It'd be a read-only folder and would only be shown to users that have one or more recursive (and direct?) pins.

It could support context actions such as "Copy to MFS/Files" and "Unpin" :)

[hacdias]

@olizilla so what would the structure of the root be? I did thought about something like this:

• MFS/Home (we'd need to give it a good name)
• Pins ? or should we list the pins alongside MFS? Or should we list the pins + interesting stuff, and the pins would have a tag telling it's a pin and a way to unpin?
• Also add some way to navigate to an arbitrary CID/IPFS/IPNS/path

[hacdias]

Some questions for things to decide:

1. On the root /, what should we should besides the MFS?
   
   
   
   1. Should we show our PINS?
   
   
   2. Or should we show something else such as ipfs and ipns as they are the two main namespaces. Then, inside ipfs, we'd have the pins.
   
   
2. Depending on your answer to the prev questions, what to show on /ipns//ipfs? Or just redirect to /?

[hacdias]

This might be out of scope and perhaps should be moved to another issue: I noticed the files page is being re-rendered like crazy for no reason. I've also noticed that we could really simplify our code if we kept most of the action code and state on the redux bundle. That way, we could connect each component to the specific bits of data they need, simplifying the code. And since it would be a "shared" state, it could help us with functionalities that involve the selected files, for instance.

I could refactor the code, and in the meanwhile introduce this change. I don't know how much time it'd take, but certainly a bit. It'd also produce a really big PR even though I'd basically use all the current components just as they are.

/cc @olizilla

[olizilla]

In general it's better to keep new features and refactors as seperate tasks. Let's make that a seperate issue.

For the "what should we show where" the goals are:

• make something useful for developers
• stay consistent with what IPFS does.

So, when you click on the files tab, ideally we'd show a few of your most recently pinned CIDs and the current CID for the MFS root, that you could click through to.

Alas, we don't have a way to get "recent pins"... it's all or nothing. We could get the full list and show it as a count like "58 blocks pinned / 2988 blocks stored", along with a link to list the recursively pinned root CIDS...

We could also change the "expore a CID" feature to show a preview of the content along with a little metadata, rather than have it open things in the IPLD explorer... In general I think folks will probably want to see the things rather than see the IPLD data behind the things.

We could show /ipfs and /ipns as special folders inside your MFS... but it's weird. With an empty MFS, the root dir would have the CID of the empty dir QmUNLL... but we'd show it as having 2 dirs in it... Not a deal breaker, but it makes it that bit harder to explain CIDs and how IPFS works to people. We could side step the issue by showing /ipfs and /ipns as visually seperate from /everything-else, but it needs some experimenting.

[hacdias]

Some ideas taken from a call today with @olizilla:

• On the main files page show the MFS root contents, a button (separated from the files list) to the pins. That "button" would have the number of pinned blocks.
• Also, show the number of blocks and perhaps some other interesting info.
• Do something like Github bar:

Oli also had an idea to let users browse the blocks (could you give more details on that one?).

Another interesting topic that came in mind is to update the main bar at the top (Explore) to Browse so it opens IPFS paths on Files page instead of explore page by default.

This thoughts need to be improved. In the meanwhile, you can take a look at #1027. It already lets you browse any files you want (/files/mfs..., /files/ipns..., /files/ipns/... and /files/pins are the main URLs).

Ideas for the navigation breadcrumbs (we'd still need a way to get back to MFS when viewing IPNS/IPFS):

Ideas for the right side actions:

[lidel]

Do something like Github bar

I like this idea a lot!

Oli also had an idea to let users browse the blocks (could you give more details on that one?).

ipfs refs local will list _all_ local references (CIDs of blocks physically present at your node's repo)

There is also
ipfs files stat --with-local /ipfs/{cid} shows what part of data behind a CID is local (kB and %)

Another interesting topic that came in mind is to update the main bar at the top (Explore) to Browse so it opens IPFS paths on Files page instead of explore page by default.

:+1: for Files to be the default view.
IPLD Explorer makes sense as an opt-in "inspector/debug view".

Ideas for the navigation breadcrumbs (we'd still need a way to get back to MFS

What if we avoid using a constantly changing CID for MFS and display the home icon as the root crumb?

/ my / path

Ideas for the right side actions

Personally I'd like to keep icon+text for Adding files and Folders, as those are key features and text makes them even more prominent. Other less often used features could be behind icons alone.

[hacdias]

Personally I'd like to keep icon+text for Adding files and Folders, as those are key features and text makes them even more prominent. Other less often used features could be behind icons alone.

Agreed. On pins page, perhaps a 'Pin' button and also add the 'Pin' option to the drop down. We will be able to navigate any files we want :O

[ericronne]

@hacdias i'm currently distracted with camp design, but _maybe_ this design which i began in collab with @olizilla can help advance the conversation. To be cont