Validity errors during single-protocol resolution on a multi-protocol namespace

[wking]

While poking around for #1350, I turned up another resolution wrinkle:

$ ipfs --debug dns --recursive tremily.us
20:35:31.997  INFO   cmd/ipfs: IPFS_PATH /home/wking/.ipfs main.go:282
20:35:31.998 DEBUG   cmd/ipfs: looking for running daemon... main.go:292
20:35:31.998 DEBUG   cmd/ipfs: Calling pre-command hooks... main.go:276
20:35:31.998 DEBUG   cmd/ipfs: Executing command locally main.go:336
20:35:31.998  INFO    namesys: DNSResolver resolving tremily.us base.go:19
20:35:32.001 DEBUG    namesys: Resolved tremily.us to /ipns/QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7 dns.go:41
20:35:32.001 WARNI    namesys: Could not resolve QmbqDJaoZYoGNw4dz7FqFDCf6q9EcHoMBQtoGViVFw2qv7 dns.go:41
Error: not a valid domain name

This is an untested side-effect of the protocol-squashing that we
decided to keep in #1208. The problem is that the recursive resolver
can't distinguish between:

a. the returned key is invalid gibberish, and
b. the returned key is part of another protocol whose namespace
overlaps with the current resolver.

So if you have a DNS link pointing into /ipfs/…, the current “I'm
done” check works fine. But for an /ipns/{domain-name} link
pointing at an /ipns/{pk-hash} link (like I have) the current DNS-only
resolution is saying “{pk-hash} isn't a domain name!” and dying. The
only solutions I can think of are:

x. Split the namespaces out by protocol (e.g. /dns/{domain-name} and
/ipns/{pk-hash} (or /ipht/{pk-hash}, or /our-dht/{pk-hash}, or
whatever)). For thoughts along this line, see here.
y. Share code between the squashed protocols so they can decide when a
given entry belongs to a different protocol that shares their
namespace.
z. Leave this as a temporary wart until we decide to go down the (x)
route.

I think my current preference is (z), but thought I'd file this issue so
other folks hitting this error would have a change at finding the
explanation.

[jbenet]

This used to work just fine. After every Resolver finished, the flow jumped back into the resolver for all, which asked every resolver using CanResolve(<name>) whether they could resolve the name. There were precedence rules.

Do we just need to revert resolution all the way back or something?

[wking]

On Wed, Jun 10, 2015 at 01:18:01AM -0700, Juan Batiz-Benet wrote:

This used to work just fine. After every Resolver finished, the flow
jumped back into the resolver for all, which asked every resolver
using CanResolve(<name>) whether they could resolve the
name. There were precedence rules.

The all-protocol resolver still does this without trouble (because it
knows about all the protocols, which is condition (y)):

$ ipfs resolve --recursive /ipns/tremily.us
/ipfs/QmXvEg83dD5PvaDUqHV17iXXtTpZMnPrpKmR2cGyU3oCK5

Do we just need to revert resolution all the way back or something?

Before #1208 we didn't have per-protocol resolver commands (e.g. ‘ipfs
dns …’ and ‘ipfs name resolve …’, but see #1307). So another
potential resolution would be:

z'. Remove the per-protocol resolver commands for namespace-squashed
protocols until we decide to go down the (x) route.

Since all of our non-Merkle namespaces are currently squashed into
/ipns/…, z' means we'd be back to a single non-Merkle resolver
command.

[wking]

New approach: don't special case /ipfs/… as “success”. Instead assume anything you can't resolve is a success, and leave it to callers to check that the returned path matches whatever criteria they have. So the all-protocol resolver would be fine with /ipns/ipfs.io returning /tiddlywinks, but ‘ifps ls /ipns/ipfs.io’ would error out.