File Browser: Native OS Integration

[lidel]

Background

Feature request spawned from discussion in #9:

Should we implement an OS integration, so you see IPFS files in your preferred file browser?
– @diasdavid, #9 (comment)

It's worth pointing out at this juncture that Dropbox has a web based file explorer as well as a native integration.
[..]
it makes sense to have a native integration to avoid alienating those users who don't understand "where the files are going", [..] familiarity is the really big one - Using something you already have (the native OS file explorer) but with extra bells and whistles is probably way easier than learning a completely new app. I'm speculating that most people nowadays are comfortable using their native OS file explorer and I reckon that's probably what Dropbox also gambled on (ahem, researched well ;)). Dropbox is pretty popular and in my experience seems to be understood well by most people technical or not.
[..]
There's also the reason that IPFS has already done a lot of low level work to expose itself as a regular Unix filesystem. It seems rude to not take advantage of that when it's so easy to do so.
– @alanshaw, #9 (comment)

Work towards native OS integration

Open Problems

• research if FUSE is a silver bullet for targeted platforms
• research how to add context actions to native file managers
• address key pain point: many FUSE libraries don’t support file locking, which many native apps rely on

Rules of Thumb

• make sure experience is seamless and intuitive on OSX and Windows (the biggest GUI-oriented user base)
• when in doubt, follow patterns established by things like Dropbox to decrease cognitive load on newcomers
• things that can't be supported via native integration can be delegated via context menus to web-based counterpart

Prior Work

• https://github.com/mafintosh/fuse-bindings

FUSE on Windows: there's a nice package called Dokany which allows us to use FUSE bindings on Windows.
– @hacdias, #9 (comment)

As for native integration, I wrote something a while ago for myself and put it up here
https://ipfs.io/ipfs/zDMZof1m1fX98cTLyC2VLe9iDQQhWgDLu5foshBSsxSWHQNuiyYV
It's a glorified wrapper for ipfs.exe and a bridge between the Windows shell.
– @djdv, #9 (comment)

[hacdias]

Native OS integration is a major bonus. Do you you imagine how easy would it be to just open your Finder/Explorer and just see a drive with the files you have on MFS? Just drag and drop without having to open a menubar application. It would also be much easier to navigate through your files.

Other awesome feature we could implement: a context menu option to "Add to IPFS". It would instantly open a Window, then we selected where to place the file and hit Add.

[lidel]

cc ipfs/ipfs-desktop#618

[Gozala]

I think providing OS level access to the MFS can be a huge step towards making IPFS a lot more useful for a lot more people. I would like to stress that it is less about having to learn new tool / interface for file management and more about the interoperability with rest of the system. It means that simple GUI-less utilities cat ~/ipfs/note.txt work all the way to desktop code editors like vscode or maybe more complex tools like photoshop.

I also want to mention that technology choice (e.g. Fuse) is far less important than overall user experience as in it should not feel alien or be more limited or it will be less useful. For example in my experience Fuse mounts seems a lot slower (especially when large number of files are involved) than working on regular directory. In that case I would argue it's better to sync local directory with IPFS than it is to add lag when writing / reading files (eventual consistency over slower operation).

I think mentioned trade-off is visible when comparing dropbox to keybase. Dropbox uses visuals (on OSX at least) to show if file had already being synced, while keybase just feels laggy.

[jessicaschilling]

Closing in favor of ipfs/ipfs-desktop#618