-
Notifications
You must be signed in to change notification settings - Fork 20
feat: .get(<cid array>) from the DAG API #216
Comments
Quick correction, this module uses the DAG API and therefore needs and function call there that can return multiple IPLD nodes. This is intertwined with the GraphSync effort. @vmx do you already have code for this? |
No, I haven't any code for this yet. |
@achingbrain now that @vmx shipped getMany on IPLD, can you look into shipping this one? It is needed for the DHT effort ipfs/js-ipfs#856 |
Just checking what the requirement is here - after chatting with @vasco-santos it doesn't sound like there's much to do from a DHT Endeavour perspective? We can expose @diasdavid have I missed something? What changes did you have in mind that would resolve this issue? |
It doesn't need to block the DHT effort but it will quickly be a issue if we do a DHT query for every single block we need to fetch. Using the .getMany is a first step towards a maintainable solution. |
Fixes ipfs-inactive/js-ipfs-unixfs-engine#216 by using one call to `dag.getMany` for all children of a given node instead of multiple calls to `dag.get`.
Fixes ipfs-inactive/js-ipfs-unixfs-engine#216 by using one call to `dag.getMany` for all children of a given node instead of multiple calls to `dag.get`.
I've implemented this in the shiny new decomposed |
Fixes ipfs-inactive/js-ipfs-unixfs-engine#216 by using one call to `dag.getMany` for all children of a given node instead of multiple calls to `dag.get`.
So that the DHT can handle multiple block requests without blasting hundreds of requests. Needed for ipfs/js-ipfs#856
The text was updated successfully, but these errors were encountered: