tl;dr: Even though its name makes it sound very low-level, MFS is actually our highest interaction level when it comes to managing files. It should be thought of "IPFS Drive", and could abstract away the need to know what 'pinning' at a low level is or means.
In the short term, the low hanging fruit is to switch our GUI applications and visual language from using the low-level Pin API to adding user data to MFS, where all files are implicitly pinned, and are also much easier to manage via Web UI.
Notes from conversation with @lidel, early Oct 2019.
With MFS, generally the thing is -- in IPFS all the stuff is under /ipfs, and everything under /ipfs is immutable. Under the CID it never changes. There’s a separate namespace called IPNS, and that’s the mutable namespace, but that’s still a one-off, say a directory, and everything under that will be immutable. But still -- this /ipfs is like a forest of everything, but not a place where you can manage those files. So MFS was added. It’s like a separate root. It looks like a file system. The thing is, every time to change things in that special directory. All those hashes -- everything that happens in the background is hidden. People don’t need to know about that.
Every time you change things in MFS, then the root CID changes. Everything in MFS is implicitly pinned (ie, it won't be garbage-collected unless explicitly removed from MFS). So it’s a way to abstract away the low-level APIs in a way that’s local, and intuitive.
[Note from MHz: @lidel pointed out that technically everything you have in MFS is announced to the network -- you can share permalink to every file/directory -- so it's best not to talk about MFS and 'privacy'. This mismatch between technical network privacy and what end users expect 'local' and 'privacy' to mean is a potential UX hurdle that should be treated with care because people will expect their local machine to automatically be 'private' in the way they understand 'this is my house versus this is your house and I need to invite you in before you can see what's inside'].
IPNS -- this is different because it’s meant to be something that is shared. MFS -- it’s more like local file representation. You automatically get permalinks.
The biggest problem with MFS is its name. Think of it like IPFS Drive, or Dropbox. This is me going on a tangent -- if you start thinking of it as a drive that’s backed by IPFS, it could be mounted in an operating system. Alan made a demo like this. Similar to Dom’s work. Dom’s working on the go side, what Alan did was on the js side.
So when you start thinking about this -- what if I had multiple drives? What if a drive here, automatically updated an IPNS. The name [MFS] suggests its really low-level stuff, but it’s actually the highest level we have.
I’ve been thinking about how to leverage the fact that it’s so high-level. Like Dropbox -- you’ve got a regular folder and it automatically updates.
The thing about this dashboard -- it’s WebUI, and we use the same one for Desktop and Companion. In Desktop, we have access to file system APIs, which we don’t from the web browser or IPFS companion. The idea is at some point Desktop will be a vessel for shipping OS-level integrations. Basically, something like Dropbox. You have Desktop, and you’re able to mount this MFS (this Drive) there. It’s not that technically challenging on the IPFS side, we have Files API. It’s mostly the challenge of making it work equally well across platforms. We don’t want to upset people on Windows for shipping stuff on MacOS.
Re: pinning and MFS. Generally this idea would be to make it possible to mount IPFS Drive, that’s the key feature of IPFS Desktop that’s not there, but should be at some point.
The idea now is to explore what could be put on with MFS without changing the core APIs. Understand the realm of possibility.
All this is great for the long term -- IPFS Drive and mounting. In the short term, the low hanging fruit is to switch our GUI applications and visual language from using the low-level Pin API to adding user data to MFS, where all files are implicitly pinned, and are also much easier to manage via Web UI. (For example, notes on the work that needs to be done in the browser extension are here: ipfs/ipfs-companion#415)