Context action to "Add to MFS"

[lidel]

<@whyrusleeping> lidel: i would absolutely love a right click 'save to mfs' thing for ipfs companion
i can haz?

Cool idea!
We've actually are been thinking about switching Upload and all "Add to IPFS" context actions to MFS.

Would appreciate some feedback:

• Should we still pin, or is presence in MFS is enough?
  (I'd say to not pin: MSF is enough, and if we remove file from MFS it can be GC'd)
• Where should we save them in MFS? I was bit worried about adding stuff to the root (/) as it may get noisy quite fast. Perhaps /added-via-ipfs-companion/? (looking for better name)
• Does it make sense to keep non-MFS versions in UI? My thinking is that we don't want duplicate entries, as they would clutter context menus.

[fiatjaf]

Should we still pin, or is presence in MFS is enough?

No, don't pin! Pinning is a great maze of despair. Once pinned, you're guaranteed to never find that thing ever again, and also guaranteed to not be able to delete it if you want. But adding to MFS + actually download the object is ideal.

Where should we save them in MFS? I was bit worried about adding stuff to the root (/) as it may get noisy quite fast. Perhaps /added-via-ipfs-companion/? (looking for better name)

I like this name.

[lockedshadow]

Definitely a great idea!

Should we still pin, or is presence in MFS is enough?

If presence in MFS is protects data from GC, that seems is quite enough. (To prevent the terrible things that @fiatjaf is talking about, pure pinning would require some kind of external pin log...)

Where should we save them in MFS? I was bit worried about adding stuff to the root (/) as it may get noisy quite fast. Perhaps /added-via-ipfs-companion/? (looking for better name)

What do you think about /ipfs-companion-uploads/? And even subdirectories for according type of content: /ipfs-companion-uploads/captured-web-pages and /ipfs-companion-uploads/uploaded-local-files. And it should be just default name — user-defined custom names would be more acceptable than only predefined ones. So what about custom field for user-defined paths?

Does it make sense to keep non-MFS versions in UI? My thinking is that we don't want duplicate entries, as they would clutter context menus.

Let's consider this point in a more generic way! In my opinion (not sure whether this opinion is shared by IPFS team or not), all IPFS-enabled applications should has a knowledge about which data they added to IPFS. Just pass data to IPFS daemon is not seems to be enough. It could be implemented as unique internal storage on the side of every of those applications — but it also could be a part of shared IPFS API, which may be easily adopted by certain apps. The second way looks more acceptable, isn't it? Thereby, it doesn't much sense to keep menu item that using ipfs add (at least without internal pin log). MFS version should be quite enough.

...But some kind of upload log that also could be stored in MFS would be pretty useful. This log should contain at least the original file name, date of upload and the original address of added resource.