[META] Solidify mental model/language for MFS add vs IPFS pin

[daviddias]

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

Pinning content is a new idea to most users, so we need to invest some energy in coming up with a good way of explaining it and helping the user build a useful mental model of how it works and why it's interesting.

A use-case for this is the data-together idea of sharing the hosting of content you feel is important. You can go to https://archives.ipfs.io/ and grab a hash for a dataset and replicate it all to your repo, to add more copies of it to the network and increase it's availability.

More simply you can use it to mark content that you think is important and you want to preserve.

On the flip side, a user should never have to think about pinning their own content. When I add a file to an app, I expect it to stay their until I choose to remove it. We need a clear mechanism to deal with managing repo-size and purging old content.

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#pinning

[lidel]

After a lot of thinking I came to the conclusion that we should not expose low level pinning to users of GUI apps. The ipfs pin API is too low level, too rigid, and provides no way to assign labels to pinned content.

In GUI apps MFS (mutable filesystem provided by ipfs.files API) should be used instead. It provides intuitive abstraction of "dropbox-like" filesystem and everything in MFS is implicitly pinned already.

Instead of:

 ipfs pin /ipfs/QmRAJM5ByzuKKpzKKisGDwBPHzYqMvVrYC2PcVhkMnP3gd

GUI apps should do:

 ipfs files cp /ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR /some-dir/persian-room-guardian.jpg

This simple change comes with a lot of added value:

• ability to provide human-readable labels for "pinned" files and directories via intuitive abstraction of file/dir names
• easy way to copy and reorganize pinned content into new directories (eg. share only a subset of data with someone)
• extremely intuitive "unpinning": users just delete files from MFS
  • no longer all-or-nothing: users may decide to keep a subset of pinned data by removing or copying single files instead of unpinning the entire root

[hacdias]

I strongly agree with you @lidel. I think it's also worth mentioning a comment from @Stebalien on go-ipfs: ipfs/kubo#4586 (comment)

[olizilla]

So we have (at least) 2 different use cases for pinning

1. I always want my files to stick around (we all agree, a gui user shouldn't have to think about that)
2. I may want to explicitly co-host someone elses content. I want to re-host climate change data to preserve it, or I want to support my friend to share hosting of a website.

You can also use the pinning API like a kind of like git fetch where you update your repo with some remote content, but you don't do anything with it right away. This kind of thing would probably be handled in GUI a little like Desktop does now, buy letting the user paste in a hash to go fetch... It's not really a job for pinning, but I mention as I did exactly that for grabbing all xkcd archive from https://archives.ipfs.io/

I'm in favour of MFS add instead of ifps pin. Before we go to deep on the implementation details, we need to figure out how to present the concept to the user. Pinning as co-hosting of public data is a significantly different use case from "share this file with a friend". We could get really creative with it. For it it be useful, we'd need a way to help people find and announce data sets that others might want. Hashbase (https://hashbase.io/) is worth looking at, as an existing p2p impl of the idea.

[hacdias]

As I've mentioned, I strongly agree we should use MFS for pinning. Although, I don't think we should use the term 'Pinning' because there are always users using the command-line version who will expect to see their 'pins' with ipfs pin ls command. Not using that name, or making it very clear we are pinning in another way.

For this, I'd suggest to get rid of the Pinning tab and do the following:

1. Add a new button that would clearly mean we want to pin a hash and not pick something from our drive.
2. Merge this two buttons into one and, after clicking, we would have to pick between file or folder (this is technically necessary on Windows. We can't have a button that picks folders and files). So, single button would lead to multiple options. And this button must clearly mean to add something from the local file system.

I would really like to start working on this, but want some feedback before starting the implementation. Any ideas/thoughts?

/cc @ipfs-shipyard/ipfs-gui-team

[akrych]

@hacdias Had exactly the same idea :) so agreed

and about name - yes, we need rename "pin" here.

[olizilla]

Beaker has a good take on the idea of pinning:

• Describes it as "Seed these files"
• Pick a duration from 1 day, 1 week, 1 month, Forever.
• It shows you the file size of what you'll be storing.
• It shows you how many other peers are seeding these files.
• More advanced controls are hidden behind a "Manage all network activity"

[lidel]

I think "seed" is the way to go 👍
Can't think of a better term to convey what ipfs.pin+ipfs.files does behind the scenes and remain familiar to the general public at the same time.

(In an effort to remove ambiguity "pin" should not be ever used in UI and should remain a low-level technical term similar to things like "DNS query" or "HTTP GET request")

Some remaining UX challenges:

• privacy concerns: how to communicate that everything in ipfs.files is "seeded" automatically?
  (can be downloaded by everyone knowing the CID of each item or directory)
  • how to guide the narrative? "Everything is Public but Unlisted by Default" ?
• how to encourage people to "Add by IPFS Path" and "seed" valuable content?
  • One way to do it would be a special yet-to-be-named directory that when opened had a short introduction about dweb principles and links to services such as https://archives.ipfs.io (but better, more like https://hashbase.io)
  • Another piece of the puzzle is to provide controls for setting limits on seeding "third party data", just like Beaker does:
    • bandwidth: may be really hard to aggregate stats per arbitrary CID, even harder to impose limits on CID level. I don't think we will have answer any time soon
    • time: while go-ipfs does not support pin timeouts yet (feature request: time limit (timeout) for pinned files and directories kubo#1718), we could implement time tracking in electron app and remove directory from ipfs.files after time picked by user passes

[olizilla]

how to guide the narrative? "Everything is Public but Unlisted by Default" ?

Good point.

With torrent apps it's pretty clear that you're both offering and receiving from the network wth things like the download/upload bandwidth totals and seeding ratio, and number of peers. I think we can get bandwidth stats per Peer ID, but not per CID right now, which is something we should flag.

[lidel]

Note to self:

We want to make it easier for desktop users by defaulting to MFS instead of low level pins, but it may be useful to provide a 'view' into low level pins as well.

For example, if user wants to inspect low level recursive pins via Files screen in Web UI, it can be "imported" via one-liner:

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

I guess we could provide "Import low level recursive pins to MFS" as a separate, on-demand feature.

[RubenKelevra]

ipfs/notes#397

This long list about adding the ability to create a Web of Trust with friends and share space with them falls in line with all you've said before.

The UI is currently way to complicated. I think we should move on and create a public and a private section. The private section won't 'sync' until you add some friends and they offer you space. Then the files will be scrambled and stored at your friend's storage.

Public files can be added in a different tab - that way the user doesn't confuse public and private files and accidentally make his private files available to the internet.

Additionally a tab with "deleted" content would be nice, this way the user can pin a file he accidentally removed.

[jessicaschilling]

@lidel and @rafaelramalho19 -- moving this into the pinning integration epic for the sake of incorporating what we can from this discussion. Just FYI 😊