Open warpfork opened 3 years ago
Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:
Finally, remember to use https://discuss.ipfs.io if you just need general support.
(I've suggested adding this to the v0.10 milestone just now, but am not sure if it will actually belong in that scope or not -- can discuss.)
@oed I think I've captured some of what you've described to me as a want here -- but please correct it if I got anything wrong here.
I did generalize it a bit -- our conversation earlier started with "graphsync", but I think the description here still fits the ask and technically managed to stay one step removed from that detail.
Thanks @warpfork, this would be a very useful feature indeed!
Per 2021-07-27 go-ipfs standup conversation, this can get done once https://github.com/ipfs/go-ipfs/pull/7976 is completed
A related internal doc is: https://www.notion.so/pl-strflt/IPLD-selectors-over-an-http-gateway-63cf0781ae304a3cb3f8f58b44649b03
@warpfork is that a doc that could be shared publicly? 🙏
FYI I just opened https://github.com/ipfs/go-ipfs/issues/8526 with a related feature request that would also be necessary to enable efficient traversal over complex IPLD data structures
2022-01-07 discussion: a big challenge is how to put selectors on the command line, but that has been solved with Lotus so we should be able to just follow suit.
Feature description:
The
ipfs dag
API should let a user ask for the daemon to fetch data matching a selector.Motivation:
Users might have large data structures that they want to work on, and want to get these locally before starting to work with them, for performance reasons; or, want to get them locally simply so they can confidentally go offline.
Ceramic has a good example story like this:
Disambiguation:
This is very similar and related to some plans for having APIs that return CAR files (because we figure those APIs should also be able to return a CAR that's matching a selector). It's slightly different, however, because the user story here involves the user being willing to make iterative requests to get the data after it's local -- it doesn't require CARs; and users could keep using their existing iterative conversational API with IPFS without changing anything, while still gettting performance improvements by nudging the daemon to get all the data ready up-front.