'Delete' modal: improve pin guidance and overall language

I was about to fill this as separate issues, but I feel it’s better to think about final UX that tries to address it all. @ipfs-shipyard/gui

Unpin by default

Situation

Right now user can pin an item via Files screen, and then use the same GUI to remove it:

Problem

If deleted item was pinned, the low level pin remains, silently protecting the CID from being garbage-collected.

This disconnect between low level pins and MFS will become a problem when we implement https://github.com/ipfs-shipyard/ipfs-companion/issues/888#issuecomment-689666068 as part of https://github.com/ipfs/ipfs-gui/issues/91. Pinning via IPFS Companion would create local pin AND add file to MFS.

Perhaps we should adjust the default behavior and remove local pin when a pinned resource is removed from MFS via GUI in Files screen?

Solution ideas

GUI users should not need to know what low level pins are, Files screen should be enough on its own for managing “pinned” data. If they remove something from “Files”, they expect it to not be kept around forever. There should be a way to keep the pin if a power user knows what they are doing, but it should not be the default behavior. Otherwise user repos will grow and they will end up with thousands of dead pins.

What if we extend the Delete dialog and display some additional UI if Deleted file is pinned?

Some ideas:

• checkbox
  • [x] Remove local pin or… [ ] Keep local pin
  • Q: should there be an option to remove remote pins too?
• button
  • Delete and unpin (make it default) and then regular Delete that keeps the pin is grayed out

No strong feeling here, but checkbox may be a better pattern if we want to provide other options, such as “remove blocks from local repo” (see below)

Clear description of what “Delete” really means

aka MFS removal vs garbage collection vs removal working only on local node

Situation

• If something is in MFS it is implicitly pinned (protected from GC).
• If user removes something from MFS, even if it is not explicitly pinned, it is still in the repo until GC, and user will see the disk space used did not change
• Even if content is GC’d, or every block is manually removed via ipfs block rm, the change is local, and the data may be safe and sound on a different node.

Problem

Due to this, “Delete” may not be the best description for the operation of “removing a pointer to a CID from MFS”.

Solution ideas

• give user an option to truly remove blocks from local repo: [ ] purge data blocks from local cache
• rename? be more honest about operation being more a Forget/Discard than “Delete”

---

Apologies for a long brain dump, but wanted to have all concerns around Delete modal in one place, so we can figure out how to improve it in premaration for pinning services integration.

Feedback/ideas will be really appreciated!

[jessicaschilling]

Sounds good, but can introduce as-is first? A little concerned about cognitive overload for three check boxes when the third does something the user can do in the menu today.

[jessicaschilling]

For your consideration/debate …