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

Links are IPFS specific #9

Open
Stebalien opened this issue Jun 23, 2017 · 6 comments
Open

Links are IPFS specific #9

Stebalien opened this issue Jun 23, 2017 · 6 comments
Labels
status/ready Ready to be worked

Comments

@Stebalien
Copy link
Member

They have name and size fields that have no meaning in IPLD.

@hsanjuan
Copy link
Contributor

hsanjuan commented Feb 8, 2019

What is the substitute for getting names? Links() now gets all the resolvable paths in an object.

Or are you planning to make it implementation-specific? But since node.Resolve(path) exists it would seem that every link has an associated path regardless of the actual node type?

@Stebalien
Copy link
Member Author

There's a Tree method that returns all paths through the object. However, that doesn't filter to paths that end at a link (it includes paths to all values within the object).

@hsanjuan
Copy link
Contributor

hsanjuan commented Feb 8, 2019

That method that would fit IPFS usecase, but I think Links() having a name was very useful to figure out which actual link you are working with when you do Links(). There should be a way to keep this around.

Effectively links have names in IPLD: they are the path that resolves to them in the node. Given that obtaining a Link in IPLD necessarily involves resolving its path in the object, I don't quite see why you cannot get that path along with the actual Link, in some way.

@Stebalien
Copy link
Member Author

The "name" in the link object just isn't the correct name and the size doesn't belong at all. Links are from the merkledag format. That is:

{
  Data: []byte,
  Links: []Link{
    {
      Name: "foobar",
      Size: 123,
      Hash: Qm...
    }
  }
}

I agree it's useful to get back paths for links but these links aren't the one's you're looking for. Really, in the above case, IPLD link name should be "Links/0/Hash".

@hsanjuan
Copy link
Contributor

How the merkledag format stores the IPLD object should not matter. If node.ResolveLink(["foobar"]) results in that link (as it does now in merkledag), then my point is that that is the name of the link.

CBOR happens to translate directly to IPLD and in the case above the name of the link would be Links/0/Hash.

@Stebalien
Copy link
Member Author

How the merkledag format stores the IPLD object should not matter. If node.ResolveLink(["foobar"]) results in that link (as it does now in merkledag), then my point is that that is the name of the link.

That's also a bug. Unfortunately, it's a really annoying bug that we're probably not going to fix until we switch to https://github.com/ipld/go-ipld-prime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status/ready Ready to be worked
Projects
None yet
Development

No branches or pull requests

3 participants