-
Notifications
You must be signed in to change notification settings - Fork 26
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
Comments
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 |
There's a |
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 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:
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 CBOR happens to translate directly to IPLD and in the case above the name of the link would be |
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. |
They have name and size fields that have no meaning in IPLD.
The text was updated successfully, but these errors were encountered: