Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion for New IPLD Interface #32

Open
patr-ck opened this issue Jan 29, 2018 · 2 comments
Open

Suggestion for New IPLD Interface #32

patr-ck opened this issue Jan 29, 2018 · 2 comments

Comments

@patr-ck
Copy link

patr-ck commented Jan 29, 2018

Just some brainstorming here, but I believe the IPLD interface could be improved upon. I think it should be changed to the following ...

type Node interface {
  func String() string
  func Loggable() map[string]interface{}
  func Cid() cid.Cid
  func Links() []*cid.Cid
  func Tree(path string, depth int) []string
  func Resolve (path []string) (Node, []string, error)
  func Value() interface{}
}

type RootNode interface {
  Node

  func RawData() []byte
}

All previous "Node"s are essentially now "RootNode"s. Cid would need to be extended to include the path portion of block traversal (for example, a full Cid could be /ipfs/hash/path/inside/block). This allows each IPFS Block to actually represent a subtree of the overall merkledag, instead of just representing a single node + links and some unspecified "stuff" inside of its path. This way, all that "stuff" becomes Nodes in the merkledag.

The distinction of root nodes from other nodes separates the Block RawData method to prevent having to deserialize the block, and likely reserialize a subportion of it to get a []byte. Even HAVING a RawData representation of the subtree is sort of useless anyways, since hashing it to verify the serialization wouldn't even work (since it's actual serialization is somewhere inside it's RootNode's serialization), and creating a RootNode Cid of the form /ipfs/hash is also pretty useless since there may not even be a file on IPFS with that subtree's data serialized data.

The benefits of doing this are: it will allow standard IPFS dag tools to work with ALL SORTS of data structures that would otherwise have been painful to implement directly on IPFS. Any sort of tree like data structure could be stored directly on IPFS without the overhead of requiring an entirely new root node CID at every single link of the tree.

I believe this can be implemented as a generalization of the existing interface as well, since everything currently called a "Node" is essentially just a "RootNode" now, and (I believe) all existing Node types (git, bitcoin, ethereum, etc) SHOULD easily be adaptable to return Node's on Resolve instead of interface{}. This is because the Cid method is essentially free (it's just the Root CID + path), Strings and Loggable are easy, and Links, Tree and Resolve should be obvious as well.

@Stebalien
Copy link
Member

Stebalien commented Jan 29, 2018

See: ipld/specs#3

I completely agree (although we would end up returning a Path from the children and only return CIDs from the roots, I don't want to start redefining what a CID is at this point). Unfortunately, fixing this at this point will be a bit hairy but we should still do it....

@Stebalien
Copy link
Member

Note: I'd also have a method on interior nodes for getting the root.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants