ipfs pin add and dag get hang when passed pin hash

[timthelion]

Version information:

go-ipfs version: 0.4.10-
Repo version: 5
System version: amd64/linux
Golang version: go1.8.3

Type:

Bug

Severity: Very Low

Description:

When I do ipfs pin add or ipfs dag get on an ipns hash it hangs indenfinitely. It would be much less confusing if it were to either work or error out saying that the given hash is an ipns entry.

Ex:

timothy@yoga ~/p/p/associate> ipfs dag get QmdJiuMWp2FxyaerfLrtdLF6Nr1EWpL7dPAxA9oKSPYYgV
^C
Error: request canceled
timothy@yoga ~/p/p/associate> ipfs name resolve QmdJiuMWp2FxyaerfLrtdLF6Nr1EWpL7dPAxA9oKSPYYgV
/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco
timothy@yoga ~/p/p/associate> ipfs dag get /ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco

{"data":"CAUSFQEABAAAAAAAAAEAAAgAAAAAAAAQACgiMIAC","links":[{"Cid":{"/":"QmPQVLHXAcDLvdf6ni24YWgGwitVTwtpiFaKkMfzZKquUB"},"Name":"0C-","Size":237360},{"Cid":{"/":"QmNYBYYjwtCYXdA2KC68rX8RqXBu9ajBM6Gi8CBrXjvk1j"},"Name":"43I","Size":44323016540},{"Cid":{"/":"QmehSxmTPRCr85Xjgzjut6uWQihoTfqg9VVihJ892bmZCp"},"Name":"58wiki","Size":613715579624},{"Cid":{"/":"QmaeP3RagknCH4gozhE6VfCzTZRU7U2tgEEfs8QMoexEeG"},"Name":"92M","Size":826},{"Cid":{"/":"QmdgiZFqdzUGa7vAFycnA5Xv2mbcdHSsPQHsMyhpuzm9xb"},"Name":"A0index.html","Size":165}]}
timothy@yoga ~/p/p/associate> 

I was confused enought by the first command hanging that I spent the mandatory 20 minutes of looking for duplicate bug reports and reporting a bug...

Related: #1467

[whyrusleeping]

@timthelion if youre referencing an ipns hash, you have to specify /ipns/QmFooBar, otherwise it assumes its an ipfs hash. Most ipfs commands assume that a bare hash is in the /ipfs/ namespace.

Its not actually possible to tell if a given hash is an ipns hash or an ipfs hash without input from the user.

[timthelion]

That is a bit tricky, but I do think that this feels like a bug. I think that I'm not the last person who will come across this behavior and assume something is broken :/. Maybe it would be appropriate to add a timeout which would test if the hash doesn't belong to ipns. If we've been waiting, say 5 seconds, and nothing has been found, and we find an ipns entry imediately, then it seems pretty safe to tell the user that it is probably an ipns entry and not an ipfs hash.

[whyrusleeping]

Yeah... That could work, but its pretty hacky. One thought is to make a new CID type for ipns, and then migrate everything up to that. We could then assume bare hashes with an ipns type should be treated as /ipns/