Command line interface for name resolution and publishing

[wking]

Since #1208 (specifically, 416d454, core/commands: Make 'ipfs name resolve' IPNS-only, 2015-05-07), ‘ipfs name resolve …’ has been for DHT-links only. Use ‘ipfs resolve’ (added in the same commit) for “use all known name-system protocols and give me back an IPFS path”.

On Sat, May 30, 2015 at 01:25:51PM -0700, Juan Batiz-Benet wrote:

Ok so then that's a problem that slipped through. TXT records are
names too and for the time being they exist under /ipns/... --
therefore "ipfs name resolve ..." should resolve them.

So what does our intended interface look like? As far as I can tell, it's:

• ipfs name resolve [--recursive] [<name>] to resolve (recursively) any name using all known protocols. Names should be fully qualified (e.g. /ipns/QmSomeKey or /ipns/example.com)
• ipfs dns resolve [--recursive] <domain-name> to resolve (recursively) name references using only DNS links. Names do not need a prefix (since the command restricts the protocol), so just use example.com.
• ipfs dht resolve [--recursive] <pk-hash> to resolve (recursively) name references using only DHT IPNS entries. Names do not need a prefix (since the command restricts the protocol), so just use QmSomeKey.

And then publish with:

• ipfs name publish [<name>] <target> to publish a reference from <name> to <target>.

I'm not sure how to handle the distinctions between the different protocols for publication. Without protocol-specific prefixes for names, should ipfs name publish [<name>] <target> be pushing a DHT entry? A DNS link? Until we do have protocol-specific namespacing, I think we probably want:

• ipfs dht publish [<name>] <target>
• ipfs dns publish [<name>] <target>
• ipfs name publish [--procotol <protocol>] [<name>] <target>.

etc. And then folks can start writing backends to push DNS links from the command line. Once we do get protocol-specific namespacing, we can drop the protocol-specific publishing commands and drop the --protocol option from the all-protocol publisher.

[jbenet]

i think this is close. some changes:

• ipfs dht resolve maybe this should be ipfs name key resolve or ipfs ipns resolve. dht is not specific. some ipfs/ipns systems will not use a dht. also "ipns" is both "the name system", and "the use-public-key-as-a-name system"
• ipfs <namesys> publish should work -- e.g. ipfs dns publish
• "all protocol publisher" -- we should have individual publish commands on each namesys. the all-protocol publisher in a sense wraps those.

[wking]

Pulling over some discussion from #1320:

On Wed, Jun 03, 2015 at 12:12:25AM -0700, Juan Batiz-Benet wrote 1:

i think there's many parts here:

1. resolving object links (just ipfs objects)
2. resolving key names (via routing records)
3. resolving dns names (via dns)
4. resolving .bit names (via namecoin)
5. resolving onion names (via tor)
6. resolving all names (everything currently under /ipns/..., key names and dns names, etc)
7. all of the above
   …
   ipfs resolve to mean (7.),
   ipfs object resolve to be (1.) above.
   ipfs name resolve and/or just ipns resolve to mean (6.) above
   ipfs dns resolve and/or just dns resolve to be (3.)

I'm fine putting 7 under a single command.

I'm agnostic about whether we want separate commands for each
protocol. The main motivation for having the per-protocol commands
was to allow per-protocol implemenations to implement just their
protocol without needing to bother with the protocols they don't care
about (see these comments [2,3,4] that seeded #1208). If we're going
to require per-protocol implementations to compile their backend into
the ipfs binary and register them with namesys/namesys.go's
mpns.resolvers map, then there's no need for separate commands for the
individual protocols. If we want to allow folks to add support for
protocols via subprocess/socket calls to an external-to-ipfs
binary/process, then I think we do want separate commands for the
individual protocols.

I'm against having separate commands that handle groupings between the
per-protocol level and the all-protocol level (e.g. (6)). That
doesn't make life easier for per-protocol name-system implementers
(who would rather focus on single-protocol implementations), and it
doesn't make life easier for users (who should only care about the
all-protocol resolver). What gap to you see (6) filling?

[wking]

On Wed, Jun 03, 2015 at 01:30:08AM -0700, Juan Batiz-Benet wrote:

• ipfs dht resolve maybe this should be ipfs name key resolve or
  ipfs ipns resolve. dht is not specific. some ipfs/ipns systems
  will not use a dht. also "ipns" is both "the name system", and
  "the use-public-key-as-a-name system"

So I'm fine replacing ‘dht’ with whatever you want to use for “the
use-public-key-as-a-name system”. If that system is protocol agnostic
(e.g. there could be several different DHTs or other non-DHT protocols
behind it), then I think we want new single-protocol resolve/publish
IPFS commands for each backing protocol, and a separate name for each
protocol. Otherwise (for example) which of several DHTs should we use
to resolve a given entry? On the other hand, if there is:

• A shared key namespace and resource spec that's distributed across
  multiple DHTs or other communications mediums, and
• There is a lower level, nameservice agnostic spec that allows for
  unambiguous lookup and publication across those backing channels,

Then having a single IPFS command for resolving/publishing to that
protcol makes sense. So the question for “do we need a separate IPFS
command for $x?” is not so much “is $x a single protocol?” (whatever
that means), but is “can I make unambiguous lookups and publications
to $x without further namespacing?”.

• "all protocol publisher" -- we should have individual publish
  commands on each namesys. the all-protocol publisher in a sense
  wraps those.

That sounds like both the ‘ipfs publish …’ (per-protocol
publication) and ‘ipfs name publish [--procotol ] …’
(all-protocol publication). Did you need me to change those patterns?

[whyrusleeping]

closing, we have ipfs resolve and ipfs dns. Thats good enough for this scope, any further requests should open a new issue