[WIP] feat(dag): add IPLD to dag.get #755
Conversation
ghost
assigned 
|
Note that go-ipfs intends to add I'd also use |
|
@magik6k thanks for looking at this! I'd love to use |
|
dag.resolve should not exist as it stands per all the conversations I, @whyrusleeping and @jbenet had in the past, both in person and async. It has been almost 2 years since the work on this API started, not worth going through all the data points, the tl;dr; is that there wasn't the opportunity to commit to an API for both implementations. I took a lot of notes along the way here, find them at:
My suggestion is for everyone to get a revisited dag API and implement it for both implementations that respects all the constraints (i.e. we can't just use JSON serialization for responses over HTTP as it messes up with types). |
License: MIT Signed-off-by: Alan Shaw <alan@tableflip.io>
| }) | ||
|
|
||
| it('should parse input as string without leading slash', () => { | ||
| const input = 'ipfs/QmUmaEnH1uMmvckMZbh3yShaasvELPW4ZLPWnB4entMTEn/path/to' |
There was a problem hiding this comment.
Should this actually be supported? I prefer having strict rules and fail early. The rule would be: path with namespaces start with a slash, if there isn't a slash it's a CID.
| const input = 42 | ||
| expect(() => ipfsPath(input)).to.throw('invalid path') | ||
| }) | ||
| }) |
There was a problem hiding this comment.
Additional test cases:
- what happens if a path has two slashes in a row (
/ipfs/CID/some//thing) - ipfs namespace without a path (
/ipfs/CID) - CID-only with a trailing slash, with and without namespace (
CID/,/ipfs/CID/)
| ], callback) | ||
| IPLDResolver.inMemory((err, ipld) => { | ||
| if (err) return callback(explain(err, 'failed to create IPLD resolver')) | ||
| ipld.support.rm(dagPB.resolver.multicodec) |
There was a problem hiding this comment.
Can you please add a comment here, why this is needed? It's clear to me, but I don't think it's clear when you read the code for the first time.
alanshaw
changed the title
|
unblocked thanks to ipld/js-ipld-dag-pb#78 |
| } | ||
| } | ||
| ], callback) | ||
| IPLDResolver.inMemory((err, ipld) => { |
There was a problem hiding this comment.
I've been thinking that this should be done by passing the ipfs.block.{get,put} as the Block Service, rather than doing an inMemory resolver and then monkey patching the Block Service Instance with a fake exchange.
You should be able to do:
const ipld = new IPLD(ipfs.block)
or close
const ipld = new IPLD(shimBS(ipfs.block))
This PR is a proposal to resolve #738 and will also fix #747.
In the
dag.getfunction we create an temporary in-memory IPLD resolver with a custom bitswap exchange hooked up to theblock.getAPI call.This is kinda awesome!
I've not implemented all the methods for the exchange, but you don't need to because it only uses
get.I created a utility module for extracting the CID and path from the
cidarg...the spec fordag.getis flexible in that you can pass it aQmhash, or aQmhash/with/pathor a CID instance but the IPLD module isn't as flexible and they need to be split into two args:CID(Qmhash)and/with/path.I've also added
explain-errorbecause it's really good at adding context to error messages whilst also retaining the original error & stack. It also means that in tests we can assert on error messages that are generated within this module rather than (possibly) randomly changing messages from dependencies.BLOCKEDThis is currently a breaking change to the way dag-pb nodes are traversed via path.
In go-ipfs you can do this:
but with this pull request, to get the same object, you'd need to:
Note "Links".