Support "ipns"

[jcea]

Could you possibly support "ipns", besides current "ipfs"?

Thanks.

[SupraSummus]

I'm not convinced to IPNS reliability enough to include its support directly in ipfs-api-mount. However I'm open to discussion.

Instead I'm thinking about "remounting" FS on the fly. You can then do a remount any time you like with any root hash. AFAIK fuse doesn't support remounting, so this has to be done in ipfs-api-mount code. I suppose the change is easy - just change root property on IPFSMount instance and disable fuse-level caching (kernel_cache). Maybe some locking is required to ensure consistency with multiple threads. New hashes may be read from stdin line-by-line. Then its possible to pipe in hash changes from another program. For example ipfs_resolve_and_watch QmAAAAAA | ipfs-api-mount /path/to/mountpoint where ipfs_resolve_and_watch outputs resolved IPNS name every time the name changes. This solution also allows to distribute new hashes via some other channel (pubsub, ssh session, wss socket, ...).

Let me know if this solution suits your use case. If it does I may implement it (and if it doesn't I might as well, because this is a cool feature in my opinion ;-) ).

[jcea]

Your proposal is interesting but a bit... bizarre. I couldn't not move around IPNS in the CLI, easily.

I like the approach of "ipfs mount" were IPNS hierachy is fully available and the resolve code is only involved when you "cd" inside a IPNS directory. Would be nice if a "cd" to an IPNS name would act as a symbolic link inside the IPFS directory, resolved at runtime.

Something like:

$ cd /ipns/Qw....
(IPNS resolution happens here)
[/ipfs/Qw...resolvedvalue]$

It would be fine to cache IPNS for the duration of the process, if there is some command to purge that cache or, less radical, to refresh that cache (and keep the old content if no resolution is available or it is taking too long)

Of course, something similar can be done as:

$ cd /ipfs/`ipfs --timeout 10s name resolve Qw...`

Maybe a shell macro would be enough.

[jcea]

Let's remember that IPNS can be resolved too via the DNS (sometimes), for example:

jcea@jcea:~$ ipfs resolve /ipns/ipfs.io
/ipfs/bafybeieltqren5gbivmavam532nvlsyxy725bpxqk77zvmaflrdyvu4yxm

[SupraSummus]

What do you mean by I couldn't not move around IPNS in the CLI, easily.? How does that prevent you from going with solution I proposed? It doesn't include using go-ipfs CLI directly. Or maybe even not at all. After modifications made to ipfs-api-mount and writing ipfs_resolve_and_watch program/script/macro (simplest version: "resolve every x minutes"), usage is completely free from traversing IPNS using CLI.

As for links: When designing ipfs-api-mount I intentionally avoided ipfs mount behaviour in respect to providing access to whole ipfs/ipns namespace. Providing access to non-listable, non-traversable space disguised as regular filesystem seems odd to me. As a result single instance of ipfs-api-mount mounts just one specific CID. With this constraint it's not possible to do filesystem links from /ipns/somename to /ipfs/somecid - latter one just doesn't exist. So before implementing IPNS links we need to implement mounting whole IPFS at once. Again - it seems quite straight forward, but I'm not convinced it's a good idea from architectural standpoint.

[jcea]

Moving around IPFS easily is a feature. The top directory being mode "111" (traverse only) is a standard practice, for instance, in shared hosting, where you don't want a user to be able to see other usernames in "/home". It is frequently used in network environments where membership is huge.

Your approach is quite uncomfortable for my usercases and requires planning in advance and waiting some time until your "watch" utility detects the change.

See, for instance, "ipfs files" interface: any change in the hierarchy will create a new "root" object. I can learn about its cid with "ipfs files stat /" and do a "/ipfs/CID" immediately. Having to wait minutes or even seconds, worse yet not knowing when the new "root" is active, is annoying. Moreover, it would require me to publish the new root via IPNS, with considerable delay and annoyance.

I also usually use IPFS to interface with several unrelated different contents. Having everything under "/ipfs/" is very convenient. Needing to kill "ipfs-api-mount" instance and launch a new one for each source I am interacting with is so inconvenient that I am still using "ipfs mount" most of the time. It is slow, but far more practical and less demanding for my mind.

Your current approach is practical when you are interacting with a single static source. That is not my use case. I interact with multiple sources and most of the time they are dynamic ("ipfs files", for instance). That situation makes this program unsuitable for me, most of the time.

I could survive with no "IPNS" support, "ipfs resolve" is easy enough, but I need "IPFS" complete hierarchy at my fingerprint.

I would want the convenience of "ipfs mount" with the speed of "ipfs-api-mount" :-).

Thanks

[SupraSummus]

I've created #33 for discussion about mounting whole ipfs