Apps and remainder paths

[jbenet]

See dylanPowers/ipfs-chrome-extension#10 (comment)

Suppose we have an IPFS Path / URI like:

/dns/ipfs.pics/view/ipfs/QmagBFqo41RrHpk3GKvBCpjrd2H61ntgaQWNMVasZuJJn3

And suppose that:

• /dns/ipfs.pics/view is an application -- say a webapp that views images
• /ipfs/QmagBFqo41RrHpk3GKvBCpjrd2H61ntgaQWNMVasZuJJn3 is an image

Naturally, the ipfs object representing /dns/ipfs.pics/view would not have the entirey of the /ipfs pathspace underneath it, but perhaps it could signal the capacity to process remainders of paths. If so, then browsers with ipfs support could run the application at /dns/ipfs.pics/view and feed /ipfs/QmagBFqo41RrHpk3GKvBCpjrd2H61ntgaQWNMVasZuJJn3 as a parameter.

The goal is to achieve something similar to how web application servers and single-page webapps do URL path routing today, or how unix filesystems can mount other filesystems at specific mount points. In both cases, the remainder of paths get forwarded on to applications underneath.

---

One possible way to achieve this is to define a special key/value in an ipfs object that sets it as a valid return value for ALL subpaths, for example, suppose the object at /dns/ipfs.pics/view included:

@mount: true
# this is just an example, the actual key-value would likely be something else entirely.

then, when an ipfs-implementation-powered browser viewed /dns/ipfs.pics/view/ipfs/QmagBFqo41RrHpk3GKvBCpjrd2H61ntgaQWNMVasZuJJn3 it would:

• traverse to /dns/ipfs.pics/view
• find no ipfs link underneath it
• find @mount: true
• loads /dns/ipfs.pics/view as a webapp
• feeds it the rest /ipfs/QmagBFqo41RrHpk3GKvBCpjrd2H61ntgaQWNMVasZuJJn3

Note:

• the "feeds it the rest" can happen trivially in javascript today: access window.location.pathname and prune out the prefix, using the rest as the argument.
• This of course has security implications and thus should be an opt in (hence defining the key/value up there).
• More sophisticated versions of this could employ url routing regex matches on the mounts before allowing them to pass through

[jbenet]

cc @mildred @davidar @cleichner @wking -- you may be interested in this

[mildred]

This seems quite complex for me. Why not, but I like the simplicity of one path = one object that could be fetched directly without needing the intelligence of a specific application. Typically, single page applications use the hash part of the URL to route to part of themselves, and I'm comfortable with that.

What's the advantage of /dns/ipfs.pics/view//ipfs/QmagBFqo41RrHpk3GKvBCpjrd2H61ntgaQWNMVasZuJJn3 over /dns/ipfs.pics/view#/ipfs/QmagBFqo41RrHpk3GKvBCpjrd2H61ntgaQWNMVasZuJJn3 except its visual aspect (apart from the fact that the # character is a valid character in a filename and paths do not have percent escaping)?

I'm not against it, I would just like to be convinced better.

[ghost]

Just a small note, don't wanna derail -- there are options laid out for /dns here: multiformats/go-multiaddr#7

[davidar]

@mildred it's not without precedent:

Regarding the file system, a suitable program can be designated as a translator for a single file or a whole directory hierarchy. Every access to the translated file, or files below a hierarchy in the second case, is in fact handled by the program. For example a file translator may simply redirect read and write operations to another file, like a Unix symbolic link. The effect of Unix mounting is achieved by setting up a filesystem translator (using the "settrans" command). Translators can also be used to provide services to the user. For example, the ftpfs translator allows a user to encapsulate remote FTP sites within a directory. Then, standard tools such as ls, cp, and rm can be used to manipulate files on the remote system. Even more powerful translators are ones such as UnionFS, which allows a user to unify multiple directories into one; thus listing the unified directory reveals the contents of all the directories.

-- https://en.m.wikipedia.org/wiki/GNU_Hurd#Unix_extensions