Merge the Resolver interface into the Node interface

[Stebalien]

It's entirely useless (and we have way to many useless interfaces) on its own.

[whyrusleeping]

FINE

[whyrusleeping]

Actually wait no, This interface is still useful. It represents the abstract 'merkle graph' element. Something implementing resolver could be a single object that represents many sub-objects (one example would be sharding, in the abstract).

[whyrusleeping]

cc @diasdavid

[Stebalien]

Good point. Although I'd like to rename it and document why it's useful. Currently, it's just a sub-interface of Node.

[whyrusleeping]

Be careful changing the names of things. @diasdavid knows where you sleep...

[daviddias]

:D

There has to be an interface that you can give to a developer, external or internal to IPFS and say "Take this and implement this interface over that Merkle Format" and once he does, it is fully an IPLD format that is resolvable through IPFS.

In JS land, we call it ipld-format, we actually have a repo just to declare that interface spec which is interface-ipld-format.

Is it possible to match that in Go (I believe this is what this repo is, but I'm avoiding assumptions)?

[Stebalien]

It is. That's why I brought this up at the IPLD deep dive.

@whyrusleeping

FYI: In the JS version of this, resolve can't operate over abstract merkle graph elements (it expects a concrete node (binary blob)). Instead, I believe there are higher-level "path resolvers" that can operate over a graph.

[daviddias]

I believe there are higher-level "path resolvers" that can operate over a graph.

That is correct. A format implementation operates at the individual node level (can do resolves to a single node), the IPLD Service/Resolver (https://github.com/ipld/js-ipld-resolver) uses all of those IPLD Format implementations to traverse over any graph.

[whyrusleeping]

Huh, well I haven't changed anything since we talked in Seattle and agreed on this code being right.

…

On Sat, Sep 2, 2017, 10:57 AM David Dias ***@***.***> wrote: I believe there are higher-level "path resolvers" that can operate over a graph. That is correct. A format implementation operates at the individual node level (can do resolves to a single node), the IPLD Service/Resolver ( https://github.com/ipld/js-ipld-resolver) uses all of those IPLD Format implementations to traverse over any graph. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABL4HOb2GKO4NqHZKuR8M5_oFlcu4Wg3ks5seZclgaJpZM4O67lg> .

[daviddias]

I didn't change how js-ipld works either. Or we are misunderstanding something right now or we missed something then. Either way, we can reach one solution.

The rationale behind js-ipld Main Resolver and Local Resolvers is that the code that touches the Block Service and knows how to jump from one format to another is just written once in the Main Resolver. This also saves the burden from IPLD Format implementors to have to think about and implement more things.

[Stebalien]

The code, as-is (in go, at least), is right. That is, there's a higher-level path resolution interface that can resolve over a DAG and a lower-level resolver interface that resolves over individual nodes.

However, using format resolvers to resolve over abstract (e.g., sharded) objects as per your comment (#24 (comment)) would deviate from this.

The abstract resolver is defined in go-ipfs/path/resolver.go and takes a special ResolveOnce function:

type Resolver struct {
	DAG dag.DAGService

	ResolveOnce func(ctx context.Context, ds dag.DAGService, nd node.Node, names []string) (*node.Link, []string, error)
}