koivunej
commented
4 years ago To visualize the "cid correlation" mentioned in the latest edit, think of cat operation on a $root. In the case of multiblock files, it'll find N links and proceed to get_block the first range-matching links[c]. Now there is a high likelyhood of any provider of $root to also have $links[c] but a decreasing likelyhood of anyone having just the subtree starting at $links[c]. This decreasing likelyhood is related to at minimum the current setting of go-ipfs which allows only creating provider records for the roots (or even just the pinned roots).
Finding providers (peers) for multihashes (since go-ipfs 0.5) or the client DHT (at least as far as koivunej understands the feature), connecting to the peers and fulfilling the wants through the found peers. We could start with a (very) slow implementation which always finds providers for the blocks, while it's likely that the first provider(s) will have the all related successive blocks and later on add a way to "tag" or "correlate" nested Cids to the single root Cid to get away by finding the root providers, maybe refreshing them later on, then only go find providers for successive blocks if all of the root Cid providers fail to send us the successive blocks.