ipfs/kubo

common interface in front of IpfsNode or HTTP API node

Closed this issue · 5 comments

hackergrrl commented

One thing high on my wish-list is a go interface that supports various IPFS node operations, but abstracts away whether it's an IpfsNode instance or a URL for an API node running somewhere. Shell comes close, but maybe mirrors the HTTP API too closely.

Having this means:

  1. the ipfs cli (and everyone else) can stop branching on "if api do this, if ipfsnode do this"
  2. we could write a package like "gimme-ipfs-node" which returns an instance of this interface, and does the legwork of first checking for a local node and, failing that, returning an ephemeral one
  3. beneath (2) there could be a packages gimme-ephemeral-node and gimme-local-node, which each hand you back this interface

Open questions:

  1. what methods would this interface expose? We should err on the side of minimalism to start, rather than overcommitting on a large interface before we know everything is necessary. (You aren't gonna need it!)
  2. what is it named? GenericIpfsNode? IpfsNodeInterface?

cc @whyrusleeping

hackergrrl commented

Current plan of attack:

We already have Shell, which abstracts HTTP API access to a node. Thanks to @cryptix we also have embeddedShell, which is a minimal interface over an IpfsNode. Both support 'add' and 'cat' with identical signatures! 🎉

I've got a basic working package up, that uses the local node and falls back to creating an ephemeral one: https://github.com/noffle/easy-ipfs-shell

whyrusleeping commented

I would be fine with calling the interface IpfsShell and renaming the one in go-ipfs-api to HttpShell or ApiShell

hackergrrl commented

👍

jbenet commented

One thing high on my wish-list is a go interface that supports various IPFS node operations, but abstracts away whether it's an IpfsNode instance or a URL for an API node running somewhere

Very much agreed. the original idea for shell called for this but we haven't done it. I would be very much in favor of this, so that we could create nodes programmatically and not have to worry whether the node is in the same process, in the same machine, or across the world. (btw, the api endpoints later on can carry auth tokens, so this will be very much a strong use case).

One way to do this is refactoring how the core package works (the node definition) so that we can use the "core api" on a node whether or not it's local.

This doc is also very relevant:

Once we extract out libp2p, and we make a proper libp2p.Node that has all the p2p crap inside of it (Network, Routing, Exchange, etc), we can pare down the Node definition, and clean up the core api. We could do this now on top of dev0.4.0.

Instead of calling this Shell i think we should just make this the ipfs.Node, use an interface and structs to implement:

package ipfs
type Node interface { ... }
type node struct { ... } // implements ipfs.Node 
------
package ipfs_api
type Node struct { ... } // implements ipfs.Node
whyrusleeping commented

Further discussion towards this should be on the core ipfs interface: https://github.com/ipfs/interface-ipfs-core