getting the merkle proof with resolver.resolve #183

wanderer · 2017-08-04T20:51:19Z

It would be nice to be able to get the full merkle proof of a path using resolver.resolve (would be exposed in ipld resolver i suppose). ipld-graph-builder could use the proofs to build its state object.

daviddias · 2017-08-04T23:52:48Z

By Merkle Proof, you mean the hash of the path? I'm happy to add that, we just need to consider the two scenarios: a) when the path leads to an object; b) path leads to a value of the object.

The answer for a) is just returning the hash of that object, however, what should we do for b)? Return the hash of the whole object? Hash that value? Open to suggestions.

wanderer · 2017-08-05T02:12:41Z

Return the hash of the whole object?

yes, i think.
I'm going to walk through an example so i can get i straight in my brain :P
Lets say we have something like

{
  '/': {
    one : {
      {
        '/' : {
          'two' : {
            '/': {
               three: {
                 val: 'value i want',
                 somethingelse : {
                    '/' : <cid>
                  }
             }
          }
          'dontwant': {
             '/': <cid>
          }
        }
      }
    }
  }
}

and we want the proof for a given root for the path 'one/two/three/val'. The most compact form of the proof would be the json above. ipld-graph-builder generates these proofs by looking up the objects individual and replacing the '/' link with the object they resolve to. But it might make sense to do it at a low low level at of the stack so a node can send a single query and retrieve the entire proof.

But I don't see anywhere in the current stack that would allow you to retrieve such a proof. So a stepping stone would be for resolver.resolve to return an array of merkle nodes it traversed through to follow a given path. So in the above example it might return something like

[
  {'one' : {'/': <cid>}},
  {'two' : {'/': <cid>}, {'dontwant': {'cid': '/'}}}.
  {'three':  {val: 'value i want'}, {somethingelse : { '/' : <cid>}},
  {val: 'value i want'},
  'value i want'
]

daviddias · 2018-06-04T08:43:50Z

//cc @alanshaw & @olizilla who are exploring this with ipfs-inactive/interface-js-ipfs-core#125

@vmx

The whole IPLD APIs get a review to make them more consistent and easier to use. Changes to compared to the current spec: - No more callbacks, everything is Promises. - `get()`: - Is renamed to `resolve()` to indicate that it also takes a mandatory path argument. - Doesn’t have a `cid` in the return value anymore. That use case is covered by returning all objects that were traversed. Their `value` will always be the CID of the next one to traverse. So if you want to know the CID of the current IPLD Node, just look at the `value` of the previously returned IPLD Node. - Doesn’t return a single value, but an iterator. - `localResolve` option is removed. If you want to resolve a single IPLD Node only, just stop the iterator after the first item. - `getStream()` is removed without replacement. Use `resolve()` which uses async iterators instead. - `getMany()` is renamed to `get()`: - takes an iterable of CIDs as parameter. - `put()`: - takes an iterable of CIDs as parameter. - Doesn’t take `cid` as an option anymore. The CID is always calculated (#175). - The options don’t take the `format` (which is a string), but the `codec` (which is a `multicodec`) (#175). - the `version` option always defaults to `1`. - `.treeStream()` is removed without replacement (the only current user seems to be the IPFS DAG API tree command and the ipld-explorer-cli). IPLD Nodes are just normal JavaScript objects, so you can call `Object.keys()` recursively on a IPLD Node to get all its resolvable paths. If you want to follow all the CIDs, write the tree traversal yourself. This could perhaps be an example bundled with js-ipld. - `remove()`: - takes an iterable of CIDs as parameter. - `.support.add()` is renamed to `.addFormat()`. - `.support.rm()` is renamed to `.removeFormat()`. Almost all open issues in regards to the IPLD API got adressed. One bigger thing is the Patch API, which also isn’t part of the current specification. Here’s an overview of the issues: - #66 - [ ] IPLD Resolver `patch` API: There is no patch API yet - #70 - [x] lazu value lookups: Can be done as IPLD Formats is pure JavaScript - [x] get external / local paths only: @vmx doesn’t know what this is, considers it a “won’t fix” - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore => won’t fix - [ ] put + patch api #66: Patch API is still missing - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix” - [x] globbing: Out of scope for js-ipld - #175 - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow `put()` with a CID - #182 - [x] API Review: Links to many other issues, I list the individual issues below - #183 - [x] getting the merkle proof with resolver.resolve: `resolve()` returns all CIDs along the traversed path - #184 - [ ] Pass down the `options` object to resolver.resolve(): This needs a custom resolver. @vmx isn’t sure if the js-ipld API should make this possible, or of it should just be easy enough to create your own resolver. - https://github.com/ipfs/interface-ipfs-core/issues/81 - [x] The `dag` API - One API to manipulate all the IPLD Format objects: Interesting discussion, but not relevant anymore. - ipfs-inactive/interface-js-ipfs-core#121 - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as the IPLD Nodes are just JavaScript objects which you can easily traverse if you like. Though `tree()`-like functionality might be added as an example or separate module. - ipfs-inactive/interface-js-ipfs-core#125 - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new `resolve()` API - ipfs-inactive/interface-js-ipfs-core#137 - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld anymore. It should be considered if `tree()` is implemented (probably as an example or separate module) Closes #182.

@vmx

The whole IPLD APIs get a review to make them more consistent and easier to use. Changes to compared to the current spec: - No more callbacks, everything is Promises. - `get()`: - Is renamed to `resolve()` to indicate that it also takes a mandatory path argument. - Doesn’t have a `cid` in the return value anymore. That use case is covered by returning all objects that were traversed. Their `value` will always be the CID of the next one to traverse. So if you want to know the CID of the current IPLD Node, just look at the `value` of the previously returned IPLD Node. - Doesn’t return a single value, but an iterator. - `localResolve` option is removed. If you want to resolve a single IPLD Node only, just stop the iterator after the first item. - `getStream()` is removed without replacement. Use `resolve()` which uses async iterators instead. - `getMany()` is renamed to `get()`: - takes an iterable of CIDs as parameter. - `put()`: - takes an iterable of CIDs as parameter. - Doesn’t take `cid` as an option anymore. The CID is always calculated (#175). - The options don’t take the `format` (which is a string), but the `codec` (which is a `multicodec`) (#175). - the `version` option always defaults to `1`. - `.treeStream()` is removed without replacement (the only current user seems to be the IPFS DAG API tree command and the ipld-explorer-cli). IPLD Nodes are just normal JavaScript objects, so you can call `Object.keys()` recursively on a IPLD Node to get all its resolvable paths. If you want to follow all the CIDs, write the tree traversal yourself. This could perhaps be an example bundled with js-ipld. - `remove()`: - takes an iterable of CIDs as parameter. - `.support.add()` is renamed to `.addFormat()`. - `.support.rm()` is renamed to `.removeFormat()`. Almost all open issues in regards to the IPLD API got adressed. One bigger thing is the Patch API, which also isn’t part of the current specification. Here’s an overview of the issues: - #66 - [ ] IPLD Resolver `patch` API: There is no patch API yet - #70 - [x] lazu value lookups: Can be done as IPLD Formats is pure JavaScript - [x] get external / local paths only: @vmx doesn’t know what this is, considers it a “won’t fix” - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore => won’t fix - [ ] put + patch api #66: Patch API is still missing - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix” - [x] globbing: Out of scope for js-ipld - #175 - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow `put()` with a CID - #182 - [x] API Review: Links to many other issues, I list the individual issues below - #183 - [x] getting the merkle proof with resolver.resolve: `resolve()` returns all CIDs along the traversed path - #184 - [ ] Pass down the `options` object to resolver.resolve(): This needs a custom resolver. @vmx isn’t sure if the js-ipld API should make this possible, or of it should just be easy enough to create your own resolver. - https://github.com/ipfs/interface-ipfs-core/issues/81 - [x] The `dag` API - One API to manipulate all the IPLD Format objects: Interesting discussion, but not relevant anymore. - ipfs-inactive/interface-js-ipfs-core#121 - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as the IPLD Nodes are just JavaScript objects which you can easily traverse if you like. Though `tree()`-like functionality might be added as an example or separate module. - ipfs-inactive/interface-js-ipfs-core#125 - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new `resolve()` API - ipfs-inactive/interface-js-ipfs-core#137 - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld anymore. It should be considered if `tree()` is implemented (probably as an example or separate module) Closes #182.

@vmx

The whole IPLD APIs get a review to make them more consistent and easier to use. Changes to compared to the current spec: - No more callbacks, everything is Promises. - `get()`: - Is renamed to `resolve()` to indicate that it also takes a mandatory path argument. - Doesn’t have a `cid` in the return value anymore. That use case is covered by returning all objects that were traversed. Their `value` will always be the CID of the next one to traverse. So if you want to know the CID of the current IPLD Node, just look at the `value` of the previously returned IPLD Node. - Doesn’t return a single value, but an iterator. - `localResolve` option is removed. If you want to resolve a single IPLD Node only, just stop the iterator after the first item. - `getStream()` is removed without replacement. Use `resolve()` which uses async iterators instead. - `getMany()` is renamed to `get()`: - takes an iterable of CIDs as parameter. - `put()`: - takes an iterable of CIDs as parameter. - Doesn’t take `cid` as an option anymore. The CID is always calculated (#175). - The options don’t take the `format` (which is a string), but the `codec` (which is a `multicodec`) (#175). - the `cidVersion` option always defaults to `1`. - `.treeStream()` is renamed to `.tree()` and returns an async iterator. - `remove()`: - takes an iterable of CIDs as parameter. - `.support.add()` is renamed to `.addFormat()`. - `.support.rm()` is renamed to `.removeFormat()`. - `options.loadFormat()` is no longer callback based but is using an async function. Almost all open issues in regards to the IPLD API got adressed. One bigger thing is the Patch API, which also isn’t part of the current specification. Here’s an overview of the issues: - #66 - [ ] IPLD Resolver `patch` API: There is no patch API yet - #70 - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript - [x] get external / local paths only: @vmx doesn’t know what this is, considers it a “won’t fix” - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore => won’t fix - [ ] put + patch api #66: Patch API is still missing - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix” - [x] globbing: Out of scope for js-ipld - #175 - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow `put()` with a CID - #182 - [x] API Review: Links to many other issues, I list the individual issues below - #183 - [x] getting the merkle proof with resolver.resolve: `resolve()` returns all CIDs along the traversed path - #184 - [ ] Pass down the `options` object to resolver.resolve(): This needs a custom resolver. @vmx isn’t sure if the js-ipld API should make this possible, or of it should just be easy enough to create your own resolver. - https://github.com/ipfs/interface-ipfs-core/issues/81 - [x] The `dag` API - One API to manipulate all the IPLD Format objects: Interesting discussion, but not relevant anymore. - ipfs-inactive/interface-js-ipfs-core#121 - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as the IPLD Nodes are just JavaScript objects which you can easily traverse if you like. Though `tree()`-like functionality might be added as an example or separate module. - ipfs-inactive/interface-js-ipfs-core#125 - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new `resolve()` API - ipfs-inactive/interface-js-ipfs-core#137 - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld anymore. It should be considered if `tree()` is implemented (probably as an example or separate module) Closes #70, #175, #182, #183 Closes ipfs-inactive/interface-js-ipfs-core#121 Closes ipfs-inactive/interface-js-ipfs-core#125 Closed ipfs-inactive/interface-js-ipfs-core#137

@vmx

The whole IPLD APIs get a review to make them more consistent and easier to use. Changes to compared to the current spec: - No more callbacks, everything is Promises. - `get()`: - Is renamed to `resolve()` to indicate that it also takes a mandatory path argument. - Doesn’t have a `cid` in the return value anymore. That use case is covered by returning all objects that were traversed. Their `value` will always be the CID of the next one to traverse. So if you want to know the CID of the current IPLD Node, just look at the `value` of the previously returned IPLD Node. - Doesn’t return a single value, but an iterator. - `localResolve` option is removed. If you want to resolve a single IPLD Node only, just stop the iterator after the first item. - `getStream()` is removed without replacement. Use `resolve()` which uses async iterators instead. - `getMany()` is renamed to `get()`: - takes an iterable of CIDs as parameter. - `put()`: - takes an iterable of CIDs as parameter. - Doesn’t take `cid` as an option anymore. The CID is always calculated (#175). - The options don’t take the `format` (which is a string), but the `codec` (which is a `multicodec`) (#175). - the `cidVersion` option always defaults to `1`. - `.treeStream()` is renamed to `.tree()` and returns an async iterator. - `remove()`: - takes an iterable of CIDs as parameter. - `.support.add()` is renamed to `.addFormat()`. - `.support.rm()` is renamed to `.removeFormat()`. - `options.loadFormat()` is no longer callback based but is using an async function. Almost all open issues in regards to the IPLD API got adressed. One bigger thing is the Patch API, which also isn’t part of the current specification. Here’s an overview of the issues: - #66 - [ ] IPLD Resolver `patch` API: There is no patch API yet - #70 - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript - [x] get external / local paths only: @vmx doesn’t know what this is, considers it a “won’t fix” - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore => won’t fix - [ ] put + patch api #66: Patch API is still missing - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix” - [x] globbing: Out of scope for js-ipld - #175 - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow `put()` with a CID - #182 - [x] API Review: Links to many other issues, I list the individual issues below - #183 - [x] getting the merkle proof with resolver.resolve: `resolve()` returns all CIDs along the traversed path - #184 - [ ] Pass down the `options` object to resolver.resolve(): This needs a custom resolver. @vmx isn’t sure if the js-ipld API should make this possible, or of it should just be easy enough to create your own resolver. - https://github.com/ipfs/interface-ipfs-core/issues/81 - [x] The `dag` API - One API to manipulate all the IPLD Format objects: Interesting discussion, but not relevant anymore. - ipfs-inactive/interface-js-ipfs-core#121 - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as the IPLD Nodes are just JavaScript objects which you can easily traverse if you like. Though `tree()`-like functionality might be added as an example or separate module. - ipfs-inactive/interface-js-ipfs-core#125 - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new `resolve()` API - ipfs-inactive/interface-js-ipfs-core#137 - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld anymore. It should be considered if `tree()` is implemented (probably as an example or separate module) Closes #70, #175, #182, #183 Closes ipfs-inactive/interface-js-ipfs-core#121 Closes ipfs-inactive/interface-js-ipfs-core#125 Closed ipfs-inactive/interface-js-ipfs-core#137

@vmx

The whole IPLD APIs get a review to make them more consistent and easier to use. Changes to compared to the current spec: - No more callbacks, everything is Promises. - `get()`: - Is renamed to `resolve()` to indicate that it also takes a mandatory path argument. - Doesn’t have a `cid` in the return value anymore. That use case is covered by returning all objects that were traversed. Their `value` will always be the CID of the next one to traverse. So if you want to know the CID of the current IPLD Node, just look at the `value` of the previously returned IPLD Node. - Doesn’t return a single value, but an iterator. - `localResolve` option is removed. If you want to resolve a single IPLD Node only, just stop the iterator after the first item. - `getStream()` is removed without replacement. Use `resolve()` which uses async iterators instead. - `getMany()` takes an iterable as input now. - `put()`: - Doesn’t take `cid` as an option anymore. The CID is always calculated (#175). - The options don’t take the `format` (which is a string), but the `codec` (which is a `multicodec`) (#175). - the `cidVersion` option always defaults to `1`. - `.treeStream()` is renamed to `.tree()` and returns an async iterator. - `.support.add()` is renamed to `.addFormat()`. - `.support.rm()` is renamed to `.removeFormat()`. - `options.loadFormat()` is no longer callback based but is using an async function. - `putMany()` and `removeMany()` are introduced which both take an iterable as input. Almost all open issues in regards to the IPLD API got adressed. One bigger thing is the Patch API, which also isn’t part of the current specification. Here’s an overview of the issues: - #66 - [ ] IPLD Resolver `patch` API: There is no patch API yet - #70 - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript - [x] get external / local paths only: @vmx doesn’t know what this is, considers it a “won’t fix” - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore => won’t fix - [ ] put + patch api #66: Patch API is still missing - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix” - [x] globbing: Out of scope for js-ipld - #175 - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow `put()` with a CID - #182 - [x] API Review: Links to many other issues, I list the individual issues below - #183 - [x] getting the merkle proof with resolver.resolve: `resolve()` returns all CIDs along the traversed path - #184 - [ ] Pass down the `options` object to resolver.resolve(): This needs a custom resolver. @vmx isn’t sure if the js-ipld API should make this possible, or of it should just be easy enough to create your own resolver. - https://github.com/ipfs/interface-ipfs-core/issues/81 - [x] The `dag` API - One API to manipulate all the IPLD Format objects: Interesting discussion, but not relevant anymore. - ipfs-inactive/interface-js-ipfs-core#121 - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as the IPLD Nodes are just JavaScript objects which you can easily traverse if you like. Though `tree()`-like functionality might be added as an example or separate module. - ipfs-inactive/interface-js-ipfs-core#125 - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new `resolve()` API - ipfs-inactive/interface-js-ipfs-core#137 - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld anymore. It should be considered if `tree()` is implemented (probably as an example or separate module) Closes #70, #175, #182, #183 Closes ipfs-inactive/interface-js-ipfs-core#121 Closes ipfs-inactive/interface-js-ipfs-core#125 Closed ipfs-inactive/interface-js-ipfs-core#137

@vmx

The whole IPLD APIs get a review to make them more consistent and easier to use. Changes to compared to the current spec: - No more callbacks, everything is Promises. - `get()`: - Is renamed to `resolve()` to indicate that it also takes a mandatory path argument. - Doesn’t have a `cid` in the return value anymore. That use case is covered by returning all objects that were traversed. Their `value` will always be the CID of the next one to traverse. So if you want to know the CID of the current IPLD Node, just look at the `value` of the previously returned IPLD Node. - Doesn’t return a single value, but an iterator. - `localResolve` option is removed. If you want to resolve a single IPLD Node only, just stop the iterator after the first item. - `getStream()` is removed without replacement. Use `resolve()` which uses async iterators instead. - `getMany()` takes an iterable as input now. - `put()`: - Doesn’t take `cid` as an option anymore. The CID is always calculated (#175). - The options don’t take the `format` (which is a string), but the `codec` (which is a `multicodec`) (#175). - the `cidVersion` option always defaults to `1`. - `.treeStream()` is renamed to `.tree()` and returns an async iterator. - `.support.add()` is renamed to `.addFormat()`. - `.support.rm()` is renamed to `.removeFormat()`. - `options.loadFormat()` is no longer callback based but is using an async function. - `putMany()` and `removeMany()` are introduced which both take an iterable as input. Almost all open issues in regards to the IPLD API got adressed. One bigger thing is the Patch API, which also isn’t part of the current specification. Here’s an overview of the issues: - #66 - [ ] IPLD Resolver `patch` API: There is no patch API yet - #70 - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript - [x] get external / local paths only: @vmx doesn’t know what this is, considers it a “won’t fix” - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore => won’t fix - [ ] put + patch api #66: Patch API is still missing - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix” - [x] globbing: Out of scope for js-ipld - #175 - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow `put()` with a CID - #182 - [x] API Review: Links to many other issues, I list the individual issues below - #183 - [x] getting the merkle proof with resolver.resolve: `resolve()` returns all CIDs along the traversed path - #184 - [ ] Pass down the `options` object to resolver.resolve(): This needs a custom resolver. @vmx isn’t sure if the js-ipld API should make this possible, or of it should just be easy enough to create your own resolver. - https://github.com/ipfs/interface-ipfs-core/issues/81 - [x] The `dag` API - One API to manipulate all the IPLD Format objects: Interesting discussion, but not relevant anymore. - ipfs-inactive/interface-js-ipfs-core#121 - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as the IPLD Nodes are just JavaScript objects which you can easily traverse if you like. Though `tree()`-like functionality might be added as an example or separate module. - ipfs-inactive/interface-js-ipfs-core#125 - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new `resolve()` API - ipfs-inactive/interface-js-ipfs-core#137 - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld anymore. It should be considered if `tree()` is implemented (probably as an example or separate module) Closes #70, #175, #182, #183 Closes ipfs-inactive/interface-js-ipfs-core#121 Closes ipfs-inactive/interface-js-ipfs-core#125 Closed ipfs-inactive/interface-js-ipfs-core#137

@vmx

The whole IPLD APIs get a review to make them more consistent and easier to use. Changes to compared to the current spec: - No more callbacks, everything is Promises. - `get()`: - Is renamed to `resolve()` to indicate that it also takes a mandatory path argument. - Doesn’t have a `cid` in the return value anymore. That use case is covered by returning all objects that were traversed. Their `value` will always be the CID of the next one to traverse. So if you want to know the CID of the current IPLD Node, just look at the `value` of the previously returned IPLD Node. - Doesn’t return a single value, but an iterator. - `localResolve` option is removed. If you want to resolve a single IPLD Node only, just stop the iterator after the first item. - `getStream()` is removed without replacement. Use `resolve()` which uses async iterators instead. - `getMany()` takes an iterable as input now. - `put()`: - Doesn’t take `cid` as an option anymore. The CID is always calculated (#175). - The options don’t take the `format` (which is a string), but the `codec` (which is a `multicodec`) (#175). - the `cidVersion` option always defaults to `1`. - `.treeStream()` is renamed to `.tree()` and returns an async iterator. - `.support.add()` is renamed to `.addFormat()`. - `.support.rm()` is renamed to `.removeFormat()`. - `options.loadFormat()` is no longer callback based but is using an async function. - `putMany()` and `removeMany()` are introduced which both take an iterable as input. Almost all open issues in regards to the IPLD API got adressed. One bigger thing is the Patch API, which also isn’t part of the current specification. Here’s an overview of the issues: - #66 - [ ] IPLD Resolver `patch` API: There is no patch API yet - #70 - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript - [x] get external / local paths only: @vmx doesn’t know what this is, considers it a “won’t fix” - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore => won’t fix - [ ] put + patch api #66: Patch API is still missing - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix” - [x] globbing: Out of scope for js-ipld - #175 - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow `put()` with a CID - #182 - [x] API Review: Links to many other issues, I list the individual issues below - #183 - [x] getting the merkle proof with resolver.resolve: `resolve()` returns all CIDs along the traversed path - #184 - [ ] Pass down the `options` object to resolver.resolve(): This needs a custom resolver. @vmx isn’t sure if the js-ipld API should make this possible, or of it should just be easy enough to create your own resolver. - https://github.com/ipfs/interface-ipfs-core/issues/81 - [x] The `dag` API - One API to manipulate all the IPLD Format objects: Interesting discussion, but not relevant anymore. - ipfs-inactive/interface-js-ipfs-core#121 - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as the IPLD Nodes are just JavaScript objects which you can easily traverse if you like. Though `tree()`-like functionality might be added as an example or separate module. - ipfs-inactive/interface-js-ipfs-core#125 - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new `resolve()` API - ipfs-inactive/interface-js-ipfs-core#137 - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld anymore. It should be considered if `tree()` is implemented (probably as an example or separate module) Closes #70, #175, #182, #183 Closes ipfs-inactive/interface-js-ipfs-core#121 Closes ipfs-inactive/interface-js-ipfs-core#125 Closed ipfs-inactive/interface-js-ipfs-core#137

@vmx

The whole IPLD APIs get a review to make them more consistent and easier to use. Changes to compared to the current spec: - No more callbacks, everything is Promises. - `get()`: - Is renamed to `resolve()` to indicate that it also takes a mandatory path argument. - Doesn’t have a `cid` in the return value anymore. That use case is covered by returning all objects that were traversed. Their `value` will always be the CID of the next one to traverse. So if you want to know the CID of the current IPLD Node, just look at the `value` of the previously returned IPLD Node. - Doesn’t return a single value, but an iterator. - `localResolve` option is removed. If you want to resolve a single IPLD Node only, just stop the iterator after the first item. - `getStream()` is removed without replacement. Use `resolve()` which uses async iterators instead. - `getMany()` takes an iterable as input now. - `put()`: - Doesn’t take `cid` as an option anymore. The CID is always calculated (#175). - The options don’t take the `format` (which is a string), but the `codec` (which is a `multicodec`) (#175). - the `cidVersion` option always defaults to `1`. - `.treeStream()` is renamed to `.tree()` and returns an async iterator. - `.support.add()` is renamed to `.addFormat()`. - `.support.rm()` is renamed to `.removeFormat()`. - `options.loadFormat()` is no longer callback based but is using an async function. - `putMany()` and `removeMany()` are introduced which both take an iterable as input. Almost all open issues in regards to the IPLD API got adressed. One bigger thing is the Patch API, which also isn’t part of the current specification. Here’s an overview of the issues: - #66 - [ ] IPLD Resolver `patch` API: There is no patch API yet - #70 - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript - [x] get external / local paths only: @vmx doesn’t know what this is, considers it a “won’t fix” - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore => won’t fix - [ ] put + patch api #66: Patch API is still missing - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix” - [x] globbing: Out of scope for js-ipld - #175 - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow `put()` with a CID - #182 - [x] API Review: Links to many other issues, I list the individual issues below - #183 - [x] getting the merkle proof with resolver.resolve: `resolve()` returns all CIDs along the traversed path - #184 - [ ] Pass down the `options` object to resolver.resolve(): This needs a custom resolver. @vmx isn’t sure if the js-ipld API should make this possible, or of it should just be easy enough to create your own resolver. - https://github.com/ipfs/interface-ipfs-core/issues/81 - [x] The `dag` API - One API to manipulate all the IPLD Format objects: Interesting discussion, but not relevant anymore. - ipfs-inactive/interface-js-ipfs-core#121 - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as the IPLD Nodes are just JavaScript objects which you can easily traverse if you like. Though `tree()`-like functionality might be added as an example or separate module. - ipfs-inactive/interface-js-ipfs-core#125 - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new `resolve()` API - ipfs-inactive/interface-js-ipfs-core#137 - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld anymore. It should be considered if `tree()` is implemented (probably as an example or separate module) Closes #70, #175, #182, #183 Closes ipfs-inactive/interface-js-ipfs-core#121 Closes ipfs-inactive/interface-js-ipfs-core#125 Closed ipfs-inactive/interface-js-ipfs-core#137

vmx · 2019-05-08T15:10:57Z

The resolver now returns all nodes from the root to the destination node when resolve() is called.

vmx transferred this issue from ipld/interface-ipld-format Nov 20, 2018

vmx added the api-review label Nov 20, 2018

vmx mentioned this issue Nov 22, 2018

Major API changes #185

Closed

15 tasks

vmx mentioned this issue Feb 7, 2019

docs: major API changes #191

Merged

15 tasks

vmx closed this as completed May 8, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

getting the merkle proof with resolver.resolve #183

getting the merkle proof with resolver.resolve #183

wanderer commented Aug 4, 2017

daviddias commented Aug 4, 2017

wanderer commented Aug 5, 2017 •

edited

Loading

daviddias commented Jun 4, 2018

vmx commented May 8, 2019

getting the merkle proof with resolver.resolve #183

getting the merkle proof with resolver.resolve #183

Comments

wanderer commented Aug 4, 2017

daviddias commented Aug 4, 2017

wanderer commented Aug 5, 2017 • edited Loading

daviddias commented Jun 4, 2018

vmx commented May 8, 2019

wanderer commented Aug 5, 2017 •

edited

Loading