Currently, when a peer doesn't support a selector, the query fails. This isn't an issue at the moment given that there's only one implementation, but it'll be come an issue as graphsync is deployed on a live network, with outdated peers, forks, new implementations, etc.
One solution is to ensure that there exist a minimal subset of selectors from which all other selectors can be derived. If we do this, graphsync could compile more complex selectors down to this minimal subset when a peer doesn't support more powerful selectors.
Unfortunately, while I believe this solution is the ideal solution, it's rather complicated and very difficult to implement correctly and efficiently. We'd need to build a selector compiler, of sorts.
A simpler alternative is to allow a responder to partially execute a selector then return results of the form "I can't execute this sub-selector on this block". The requester would then pick up where the responder left off (the requester needs to follow along and execute the same query anyways). Once the requester reaches blocks it doesn't have, it would again package up the sub-selector along with the missing CIDs, and make a new graphsync request.
This proposal is really just a combination of two features:
The ability to partially execute a selector and create a new selector to continue from where the execution stopped. Both the requester and the responder will use this: the requester when they run into a missing block, and the responder when they run into an unsupported selector (or when they run into a missing block).
The ability for the responder to say "I don't support this selector".
Currently, when a peer doesn't support a selector, the query fails. This isn't an issue at the moment given that there's only one implementation, but it'll be come an issue as graphsync is deployed on a live network, with outdated peers, forks, new implementations, etc.
One solution is to ensure that there exist a minimal subset of selectors from which all other selectors can be derived. If we do this, graphsync could compile more complex selectors down to this minimal subset when a peer doesn't support more powerful selectors.
Unfortunately, while I believe this solution is the ideal solution, it's rather complicated and very difficult to implement correctly and efficiently. We'd need to build a selector compiler, of sorts.
A simpler alternative is to allow a responder to partially execute a selector then return results of the form "I can't execute this sub-selector on this block". The requester would then pick up where the responder left off (the requester needs to follow along and execute the same query anyways). Once the requester reaches blocks it doesn't have, it would again package up the sub-selector along with the missing CIDs, and make a new graphsync request.
This proposal is really just a combination of two features: