ipfs mount

[hackergrrl]

ipfs mount is great, but it could be a lot more powerful and also borrow a lot of well established UX from the unix mount command. (known as the principle of least surprise)

$ ipfs mount
Usage: ipfs mount [-a | --all]
       ipfs mount [-r | --read-only] <ipfs-path> <local-path>

Options:
  -a, --all                   mount all filesystems in .ipfs/fstab
  -r, --read-only             mount as read-only (only useful for /ipns paths)

mounting

Arbitrary IPFS and IPNS paths can mounted to the local file system. A user should be able to mount all of /ipfs somewhere, and then also mount /ipfs/Qmfoobarquux elsewhere.

• ipfs mount /ipfs/Qmfoobarquux /home/stephen/my-website
  • mount a particular path to a location
• ipfs mount /ipfs
  • mount just /ipfs to default location
• ipfs mount /ipfs /tmp/ipfs
  • mount just ipfs to custom location
• ipfs mount /ipns
  • mount IPNS to default location
• ipfs mount -r /ipns
  • mount IPNS as read-only

listing mountpoints

$ ipfs mount
/ipfs                 /tmp/ipfs
/ipfs/Qmfoobarquux    /home/stephen/my-website
/ipns                 /ipns

Here and throughout, output should be textual, line based, and trivial for external tooling to parse.

mounting all

ipfs mount -a

It should be possible to configure mountpoints somewhere -- probably in .ipfs. Maybe in .ipfs/fstab.

additional

• fstab data should be a proper ipfs object (json/cson/yml), either in its own file or just as a subobject inside the config (this is to ensure the repo itself remains representable as IPFS objects)
• let's break backwards compatibility and use ipfs mount to list, BUT only if we add a compatibility message at the end, like:

$ ipfs mount
/ipfs                 /tmp/ipfs
/ipfs/Qmfoobarquux    /home/stephen/my-website
/ipns                 /ipns
# The mount command has changed, it now lists tracked mountpoints.
# For the original behavior -- mounting the mountpoints -- use:    ipfs mount -a

---

cc @jbenet @whyrusleeping @diasdavid @lgierth @rht

[Kubuxu]

If list is supposed to be easy to parse, I would left out the colon and just make first line a columns decryption (like ps).

[rht]

I take the usage of 'UX' here as specifically to refer to having 'least surprise', which is also the case with the files API for local operations.
For the files api, it is unclear whether it should grow to have feature parity with coreutils, or just to support POSIX file operations. Implementing the POSIX interface in the context of distributed fs is tough and will take lots of research (plenty incompatible standards to sift through). While the issue with implementing coreutils-like local operations is that there are also plenty standards to sift through (among darwin, any bsd, linux, ...).

What is concerning of ipfs mount, imo, is the perf. A well-thought ux won't substitute for this. Otherwise it could have been used to mount /nix/store or to be used as git-annex's backend by now.
To this date, there is no performant bittorrent fs to base on. Should this (ipfs mount ux/perf) really be the current focus of ipfs devs? Shouldn't optimizing for content-delivery use case be the first to be nailed? (i.e. refine the 'git' and 'torrent' part of ipfs first, then later unixfs)
From git-blame stat of fuse/**/*.go: cc @cryptix, @tv42

[hackergrrl]

@Kubuxu: Agreed. If we really wanted to be consistent with mount we'd do something like tmpfs on /tmp type tmpfs (rw) per line, but this seems pretty unpleasant to parse using traditional methods.

@rht: Yes, UX roughly equates to the principle of least surprise here. I've updated the root comment.

[jbenet]

@noffle i really like this. +1.

Additions:

• fstab should be a proper ipfs object (json/cson/yml), either in its own file or just as a subobject inside the config (this is to ensure the repo itself remains representable as IPFS objects)
• agree with @rht that perf is very important. (what is the relevance to this topic, @rht? not sure the UX presented here causes reduction in perf)
• if we want to keep backwards compat, we can make ipfs mount alias to ipfs mount -a, and ipfs mount ls be the listing.
• though i'm fine breaking backwards compatibility and use ipfs mount to list, IF we add a compatibility message at the end, like:

$ ipfs mount
/ipfs                 /tmp/ipfs
/ipfs/Qmfoobarquux    /home/stephen/my-website
/ipns                 /ipns
# The mount command has changed, it now lists tracked mountpoints.
# For the original behavior -- mounting the mountpoints -- use:    ipfs mount -a

---

One unrelated-to-this-UX-but-worth-considering-now thing is:

• I would also like this to be possible to use as a separate command/tool -- i.e. that can be shipped separately or with the ipfs binary.
• the former is for isolation and cleanliness and would go over the daemon's API, as @whyrusleeping has suggested.
• and latter is for performance, because some will want to eeek out higher perf, and piping FUSE ops through yet another API crossing kernel boundaries will mega suck.
• fine to start just as is (within the binary) and then later think about extracting.

[hackergrrl]

Good points @jbenet, thanks for the input. I've updated the top issue. I'd also be okay if we did the ipfs mount -> ipfs mount -a alias with a deprecation warning.