OS integration

# OS integration # Actions 1. Create a comprehensive WebDAV overview/document of what's learned thus far and how "native" WebDAV support will feel in desktop platforms (a feature matrix table) 1.1 Blog post 2. Investigate how native it can be with platform API's (proof of concept potentially for windows?) 2.1 Blog post How do we want to integrate IPFS in a platform that makes it feel native to the user. By native i mean that the user can open `ipfs://<cid>` in the application of choice (gimp, photoshop, notepad, vlc, explorer, lightroom, blender, word, ...) and expect it to just work. ## Who are the friendlies? * Windows * macOS * Linux * Android * iOS * space? ### What about mobile (iOS and Android) integration What does native integration mean on mobile platforms? You can mostly forget tooling support on mobile. That leaves app integration where app X can use resources from IPFS. Some guesswork. * Do we need an "IPFS App" just so that we can "share data" with other apps (with the mobile share menu thingy, whatever it's called)? * We do: Durin! * Is there a mechanism for app X to pull data from an IPFS app? * TODO: build OS-specific libraries in native code, eg Swift/Kotlin. Berty has done some of this. * Native Android support * could do something w/ open source Android and see if forks are interested... * ??? There are some generic approaches that could potentially give this native feeling. Below is a listing of potential ways to go about this. ## WebDAV ### Pros * Supported on the big 5 * * Can be integrated into the Gateway, meaning every node exposing a gateway is an endpoint for webdav too! (good!) * Fairly easy to explain to users how to use this (low barrier of entry) * (w.r.t. desktop), no additional applications needed. \* Windows, mac, linux android and ios support. The support varies per platform. The platform might allow WebDAV but not out of the box. This is most notably true on mobile where you have to get an app that supports WebDAV. The desktop platforms all seem to provide WebDAV out of the box. ### Cons * Reliant on WebDAV support in clients. Which is in poor shape. * Some clients support streaming, some don't. This means for those that don't (windows and linux for sure, not sure about mac) that opening a file means it's downloaded first then opened. Fine for a few KB's, not so much for larger files. ## True native filesystem integration Think of attaching a USB drive, that's native. Proposal: (just kidding) We create IPFS USB drives :) Particularity macOS and Windows seem to have (internal) API's that expose cloud storage as if it's native to the OS. Think of iCloud on macOS and OneDrive on Windows. They integrate flawlessly (note: i only know for OneDrive) and feel like they are native to the host OS. Any apps on there can easily use files from those clouds as if they were local files. A huge downside here is that there is no - that I'm aware of - platform abstraction to provide. This means that a custom solution would have to be made on every platform to make native IPFS integration possible. Suffice to say, this is an immensely large task! If such a task were to be started, which platform would be first? Where would the priority for IPFS be? This kinda depends on where IPFS wants to place itself.. Like: * Are we a developer tool? * Are we a backend to platforms? * Are users expected to be using IPFS directly? * etc... Resources for reference. ### Windows An integration like OneDrive is achievable with https://docs.microsoft.com/en-us/windows/win32/cfapi/build-a-cloud-file-sync-engine This would allow native integration and even would allow visualizing pinned files! Though the definition of pinning is different here. To the windows API it means the file is stored locally and remotely. ### macOS They might have something that even works on iOS https://developer.apple.com/videos/play/wwdc2021/10182/ If it does and works how i hope it does then this would give a very native feeling of IPFS on both macOS and iOS (good!). I haven't researched this any deeper so i could be way off and this might not even be the right API. So fair warning. ### Linux There are a load of different ways to go about this on Linux. Also, i assume native here means desktop environment agnostic. In other terms, not any of the solutions that KDE/Gnome provide for this in their IO stacks. 1. A native IPFS block device (in kernel) with an IPFS specific filesystem driver some layers up. 2. Also a block device but using FUSE (BUSE). This does simplify development but only in terms of more flexibility. It remains a ton of work. 3. ... ## Meeting notes on linux you dont even have api for tray icon that is reliable * https://github.com/ipfs/ipfs-desktop/pull/2159#pullrequestreview-996928153 * https://github.com/ipfs/ipfs-desktop/issues/1153 * ;D only "desktop specs" i know are: * https://specifications.freedesktop.org/ * in general there is only https://en.wikipedia.org/wiki/POSIX and everything else is yolo organize pins - where's my stuff * https://github.com/ipfs/go-ipfs/blob/master/docs/experimental-features.md#ipfs-filestore OS-wide ipfs:// and ipns: scheme handler - prior art in ipfs-desktop: https://github.com/ipfs/ipfs-desktop/blob/d78b2d4921ac23cc66196f2e224bec734d5ff624/DEVELOPER-NOTES.md#manual-testing - (dont know the low level details, we most likely use whatever Electron/Chromium does) - would be useful to figure out options for registering OS-wide handler on each platform that are independent of Electron, allowing alternative IPFS implementations to register handlers themselves - ending note on communicating our work - blog posts: document explored areas, or hint at future work, allow people to quickly get up-to-speed and improve further - open PR drafts with RFC spec outline against ipfs/specs repo: allow communicty to validate idea and fill any gaps