Go-ipfs: IPFS mount & "could not resolve name"

[palkeo]

Hi !

I encountered an issue with « ipfs mount » : trying to access an invalid multihash (I forgot the last character) made « ipfs mount » display « could no resolve name » and quit, removing the mount point. Can you just display an error (with the name you could not resolve, BTW), but leave it running ?

Also, I'd like to see a message when running « ipfs mount », telling me that IPFS/IPNS are now mounted, with their respective paths.

And to finish, each time I do « ipfs mount », it tells me « could not resolve name » (I don't know which name…), and quit a dozen of seconds later and unmount the mount point. So I just can't use the mount points :(

Thanks ! (Maybe I can try to fix these issues by myself, but I want your opinion and guidance on that anyway !)

[whyrusleeping]

ping @noffle

[noffle]

Thanks for taking the time to comment, @palkeo!

This is a somewhat common problem: in order to mount /ipns, ipfs mount tries to get the latest published value for your node's public key on the network. In the case that you haven't published anything ever or a long time and it vanishes from the network, IPFS will fail to resolve your own public key and mounting will fail. We're working on this.

One workaround is to publish something to the network first, and _then_ mount. The daemon will be able to find your IPNS entry on the network and allow you to proceed:

$ echo 'hello' | ipfs add -q
QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN

$ ipfs name publish QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN
Published to QmRc5iJERYKMjFsJ57jsxJhUjf86HL1WyqrQBTJrCCAnKN: QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN

$ ipfs mount -f /tmp/ipfs -n /tmp/ipfs
IPFS mounted at: /tmp/ipfs
IPNS mounted at: /tmp/ipns

[palkeo]

The issue you mentionned seems different : it's about DNS-like caching & TTL, right ?

For this one, maybe you could just gracefuly fail if you are not able to resolve the public key on the node, and consider that nothing was published before, right ?

If you want, I can try to work on that one :)

[noffle]

There's been much discussion on this before. I don't have a quick 'n easy summary of where it's at, but here's some reading to get you started:

https://github.com/ipfs/go-ipfs/issues/2078
https://github.com/ipfs/go-ipfs/issues/2178
https://github.com/ipfs/go-ipfs/issues/2278
https://github.com/ipfs/notes/issues/109

[palkeo]

Thanks for the links !
Still, I feel that there is a fundamental difference between caching of general IPNS links, and that specific case of the node's own public key.
For the public key, can't we just try to resolve it in the background (for the unlikely case of another node with the same private key as us that would have published stuff), and if that fails we just fallback to the local value.
And if you want to ensure you are always correct, you could also (still in background) try to resolve the public key every N minutes, or even ask every new node we connect to if he has an update, just in case ?

And anyway, I think that failing to resolve our own public key should never be a failure as it is now, and we should fallback to what we have locally.

What do you think ? (don't hesitate to tell me if my assumptions are not correct !)

[noffle]

I think that failing to resolve our own public key should never be a failure as it is now, and we should fallback to what we have locally.

I agree 100%. Assuming Juan (cc @jbenet) has no qualms either -- I think he may have in the past? -- I think you should absolutely make this happen. +:100:

[mariokamenjak]

I got the same bug, luckily it worked after I did what @noffle posted in his first comment.

[whyrusleeping]

We should work on failing more gracefully here. I think this is worth bumping to a development milestone

[Kubuxu]

Resolved in #3728