GitLab

Rework mutable namespace resolution to handle recursion

Shifting the generic testResolution helper from the protocol-specific
dns_test.go to the generic namesys_test.go.

So we can attach a mock lookup function for testing.

Previously we had a confusing situation, with:

* single-arg doc: published name <name> to <value>
* double-arg doc: published name <value> to <name>
* implementation: Published name <name> to <value>

Now we have the uniform:

  Published to <name>: <value>

With the following goals:

1. It's clear that we're writing <value> to <name>'s IPNS slot in the
   DHT.
2. We preserve the order of arguments from the command-line
   invocation:

     $ ipfs name publish <name> <value>
     Published to <name>: <value>

And add a generic 'ipfs resolve' to handle cross-protocol name
resolution.

This lets users resolve (recursively or not) DNS links without pulling
in the other protocols.  That makes an easier, more isolated target
for alternative implemenations, since they don't need to understand
IPNS, proquint, etc. to handle these resolutions.

For explicitly enabling recursive behaviour (it was previously always
enabled).  That allows folks who are interested in understanding
layered indirection to step through the chain one link at a time.

This allows direct access to the earlier protocol-specific Resolve
implementations.  The guts of each protocol-specific resolver are in
the internal resolveOnce method, and we've added a new:

  ResolveN(ctx, name, depth)

method to the public interface.  There's also:

  Resolve(ctx, name)

which wraps ResolveN using DefaultDepthLimit.  The extra API endpoint
is intended to reduce the likelyhood of clients accidentally calling
the more dangerous ResolveN with a nonsensically high or infinite
depth.  On IRC on 2015-05-17, Juan said:

15:34 <jbenet> If 90% of uses is the reduced API with no chance to
  screw it up, that's a huge win.
15:34 <wking> Why would those 90% not just set depth=0 or depth=1,
  depending on which they need?
15:34 <jbenet> Because people will start writing `r.Resolve(ctx, name,
  d)` where d is a variable.
15:35 <wking> And then accidentally set that variable to some huge
  number?
15:35 <jbenet> Grom experience, i've seen this happen _dozens_ of
  times. people screw trivial things up.
15:35 <wking> Why won't those same people be using ResolveN?
15:36 <jbenet> Because almost every example they see will tell them to
  use Resolve(), and they will mostly stay away from ResolveN.

The per-prodocol versions also resolve recursively within their
protocol.  For example:

  DNSResolver.Resolve(ctx, "ipfs.io", 0)

will recursively resolve DNS links until the referenced value is no
longer a DNS link.

I also renamed the multi-protocol ipfs NameSystem (defined in
namesys/namesys.go) to 'mpns' (for Multi-Protocol Name System),
because I wasn't clear on whether IPNS applied to the whole system or
just to to the DHT-based system.  The new name is unambiguously
multi-protocol, which is good.  It would be nice to have a distinct
name for the DHT-based link system.

Now that resolver output is always prefixed with a namespace and
unprefixed mpns resolver input is interpreted as /ipfs/,
core/corehttp/ipns_hostname.go can dispense with it's old manual
/ipfs/ injection.

Now that the Resolver interface handles recursion, we don't need the
resolveRecurse helper in core/pathresolver.go.  The pathresolver
cleanup also called for an adjustment to FromSegments to more easily
get slash-prefixed paths.

Now that recursive resolution with the namesys/namesys.go composite
resolver always gets you to an /ipfs/... path, there's no need for the
/ipns/ special case in fuse/ipns/ipns_unix.go.

Now that DNS links can be things other than /ipfs/ or DHT-link
references (e.g. they could be /ipns/<domain-name> references) I've
also loosened the ParsePath logic to only attempt multihash validation
on IPFS paths.  It checks to ensure that other paths have a
known-protocol prefix, but otherwise leaves them alone.

I also changed some key-stringification from .Pretty() to .String()
following the potential deprecation mentioned in util/key.go.

RFC 6763 requires printable ASCII except '=' for the key [1], but
allows any character including '=' in the value [2].  This patch
adjusts our parsing to avoid splitting on '=' in the value, and then
ignoring anything after that split.

[1]: https://tools.ietf.org/html/rfc6763#section-6.4
[2]: https://tools.ietf.org/html/rfc6763#section-6.5

What they are, why you'd use them, and which command-line tools you
can use to access this functionality.

This is already handled by setup in namesys/routing.go:

  var log = u.Logger("namesys")

t0040: add tests for ipfs cat with stdin

.travis: split go and sharness tests

Following: https://github.com/ipfs/infrastructure/issues/20#issuecomment-102665147

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

bitswap/test: fix timeout on travis

Seems to be too unstable?

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

Add gofmt check

remove unnecessary flush, and buffer output channel

removed braintree/manners

Improve stdin parsing

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

This should fix issue #1196 (Can't launch a command line
process from Qt).

The check was bad because it took stdin into account,
but it really shouldn't.

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

This should fix issue #1141 (ipfs cat "multihash too short"
error when using stdin) and perhaps others.

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

Fix documentation on swarm connect.

Get travis to test all commits

go-peerstream update (accept concurrency)

https://github.com/jbenet/go-peerstream/commit/8d52ed2801410a2af995b4e87660272d11c8a9a4