# IPNI Community Calls

- this document: https://hackmd.io/TDMpVUdBTg6OL9TX20lmSQ?edit

## 6 Oct 2025

- Participants: will, mosh, molly, danny, bumblefudge, mattober
- [debugging a specific user's errors and timeouts]
- for fil providers - we have 15-20 providers that are in the same timeout state
- Status
- 2 of 3 instances caught up
- 3rd (SF1) about to (re)start w/ car catchup
- Spot check mechanism (Matt)
- Fallback: other things getting queried at indexstar (similar to Lassie)
- flagging queries (self-identified by query param) that skip the fallback list
- new func lets providers validate that they're caught up (spot-checking local against a few queries)
- Matt: what if there was a way to measure cid.contact against fallbacks, i.e., "this req wasn't on cid.contact, we fell back and got it from the fallback list" for groundtruth about how well cid.contact is working
- WS: we can do this at scale rather than with specific requests, given recent PRs
- Mosh: Where will this live? How can users see those?
- WS: Currently it's prometheus and that shows up in grafana but we need to make it accessible
- it could be made accessible over a GET endpoint, like we do with per-provider metrics already);
- raw metrics aren't very meaningful, tho, so we're afraid to expose those as-is, might accidentally give false-positives and false-negatives; there is a bit of a precedent in Fil+ of these metrics being interpreted far afield of providers assessing ipni health or their own providing performance
- Matt: put it behind a password? API token?
- Mosh: yeah, of course, password-gated is infinitely better than "DM will every time you're confused"
- Monitoring
- Clarification from matt (after the call) - Previously we had issues where things were "announced" (our chain was caught up), and CIDs announced before that date were not being delivered via cid.contact, but they were being delivered via our indexer.pinata.cloud router which uses the same underlying chains. The graph mentioned above would be helpful (some graph showing % of requests delivered by the fallback providers when cid.contact failed to find the CIDs internally).
- https://dev.probelab.io/ipfs/ipni/cid.contact is public dashboard
- WS: but it's only coarse info per-[HTML] error code ; better metrics should be possible soon
- Script for verifying providing as a publisher [here on github](https://github.com/ipni/ipni-cli/blob/main/pkg/verify/verify.go)
- Debugging matt's technical issue (tooling says we're caught up but the specific CIDs 404)
- WS: contextID usage differs between Fil providers and IPFS publishers (the former already need to track for deal purposes); might need to replay whole announce chain and figure out which block of announcements got swallowed and how