You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 6, 2026. It is now read-only.
We need to add a new Spark measurement that tests how many deals (CIDs) can be retrieved from the network using any available retrieval provider, including non-Filecoin nodes running IPFS.
If a piece is stored with multiple SPs but only one of them serves retrievals, the new score should flag this content as retrievable. That matches the experience of retrieval clients: they wanted to retrieve a CID and they got back their content, all was good.
The new score Should demonstrate the real-world benefits of content addressing and IPFS-based retrievals.
Proposed algorithm:
If the current retrieval check passes, the outcome of the new check is "OK".
If the current retrieval check fails because of IPNI error (e.g. 404), the outcome of the new check is the same.
Only when the IPNI lookup fails with NO_VALID_ADVERTISEMENT, we want to try to retrieve the payload CID from a random providers found in the IPNI lookup response. (Potentially de-duplicating entries from the same provider but with different protocols.)
Advertisements supporting HTTP retrieval should have higher chance of getting picked over those supporting Graphsync only
Advertisements where ContextID starts with ghsA should have higher chance of getting picked