GitLab

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.

This commit allows arbitrary json input to set.
It also tests this with sharness.

some golinting along the way

- NewDagReader() used the wrong context
- Ip?sPathPrefix isn't used anywhere
- a little bit of error handling cleanup

commands/object: remove objectData() and objectLinks() helpers
resolver: added context parameters
sharness: $HASH carried the \r from the http protocol with
sharness: write curl output to individual files
http gw: break PUT handler until PR#1191

Currently garbage collection is triggered manually and there are no
age-restrictions on the removal.  I expect we'll eventually follow Git
and auto-launch garbage collection when we hit some threshold of disk
consumption (gc.auto).  I expect we'll also follow Git and keep
unpinned or unreachable objects (gc.pruneexpire, etc.).  But we don't
seem to do either of those yet.

I'm not entirely clear on the role that this package is filling, but
this description seems like a reasonable guess based on a quick skim
through it's exported API.

The last references to CastToReaders were commented out in 6faeee83
(cmds2/add: temp fix for -r. horrible hack, 2014-11-11) and then
removed completely in 032e9c29 (core/commands2: Updated 'add' command
for new file API, 2014-11-16).

The last references to CastToStrings was removed in a0bd29d5
(core/commands2: Fixed swarm command for new arguments API,
2014-11-18).

So folks looking in core can figure out how it fits into the
repository as a whole.

Discussion in [1].

[1]: https://github.com/ipfs/go-ipfs/issues/1158

If you want to get only the hashes (i.e. the previous behaviour), you can use
the `--quiet` flag.

Also changed the ipns dns resolution to use the "dnslink" format

Catch up with core/commands/add.go.

The change to an array of readers comes from e096060b
(refactor(core/commands2/add) split loop, 2014-11-06), where it's used
to setup readers for each path in the argument list.  However, since
6faeee83 (cmds2/add: temp fix for -r. horrible hack, 2014-11-11) the
argument looping moved outside of add() and into Run(), so we can drop
the multiple-reader support from add().

Adding a file can create multiple nodes (e.g. the splitter can chunk
the file into several blocks), but:

1. we were only appending a single node per reader to our returned
   list, and
2. we are only using the final node in that returned list,

so this commit also adjusts add() to return a single node reference
instead on an array of nodes.

the random permutaton for bootstrap peers was not working as
intended, returning the first four bootstrap peers always.
this commit fixes it to be a random subset.

Once the server is asked to shut down, we stop accepting new
connections, but the 'manners' graceful shutdown will wait for
all existing connections closed to close before finishing.

For keep-alive connections this will never happen unless the
client detects that the server is shutting down through the
ipfs API itself, and closes the connection in response.

This is a problem e.g. with the webui's connections visualization,
which polls the swarm/peers endpoint once a second, and never
detects that the API server was shut down.

We can mitigate this by telling the server to disable keep-alive,
which will add a 'Connection: close' header to the next HTTP
response on the connection. A well behaving client should then
treat that correspondingly by closing the connection.

Unfortunately this doesn't happen immediately in all cases,
presumably depending on the keep-alive timeout of the browser
that set up the connection, but it's at least a step in the
right direction.

When closing a node, the node itself only takes care of tearing down
its own children. As corehttp sets up a server based on a node, it
needs to also ensure that the server is accounted for when determining
if the node has been fully closed.

The server may stay alive for quite a while due to waiting on
open connections to close before shutting down. We should
find ways to terminate these connections in a more controlled
manner, but in the meantime it's helpful to be able to see
why a shutdown of the ipfs daemon is taking so long.