ipfs
Links are IPFS specific
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?
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).
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.
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".
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.
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.