Analyze QmeLvFK9dBLhC3kbfc58mLntUei6s7fZUGWsm1xJhczm1S object

[byo]

When queried through https://cid.contact/cid/QmeLvFK9dBLhC3kbfc58mLntUei6s7fZUGWsm1xJhczm1S :

$ curl -s https://cid.contact/cid/QmeLvFK9dBLhC3kbfc58mLntUei6s7fZUGWsm1xJhczm1S | jq '.MultihashResults[].ProviderResults | length' 
26244

When queried through kubo node, object is reported as not found.

[byo]

Results are for 6 providers:

$ curl -s https://cid.contact/cid/QmeLvFK9dBLhC3kbfc58mLntUei6s7fZUGWsm1xJhczm1S | jq '.MultihashResults[].ProviderResults[].Provider.ID' | sort | uniq -c
    164 "12D3KooWCR2WA9dvHkP1ERXj2sq2G7LmrxyFoay5pfEEid21iEQy"
   4696 "12D3KooWDRHr76mnFyZ8YV888iEtPWxhDu8aiLhQvEVPrXMwXQk5"
   8306 "12D3KooWFtzeYVUSvGhPpqumswexNwhN2vw12vfaMLb77eDXodxN"
    154 "12D3KooWHKDPJM79wy2TKUL7ajWKz9zjw1aoX5nCXNfZBMH3aEYf"
   4630 "12D3KooWLYDhmYYUnPzqu5nhj7kEuuDKWTdwHdPKUSF41TLXoqsi"
   8294 "12D3KooWRpdDBcZvyDMGH8WLyFwAbJ8HWch1bbW2ShmH3kS99VUF"

Total 12 addresses (one for graphsync, one for http):

$ curl -s https://cid.contact/cid/QmeLvFK9dBLhC3kbfc58mLntUei6s7fZUGWsm1xJhczm1S | jq '.MultihashResults[].ProviderResults[].Provider.Addrs[]' | sort | uniq -c
     82 "/dns/113.23.169.21/tcp/51094/http"
     77 "/dns/113.23.169.21/tcp/55418/http"
   4147 "/dns/14.238.44.27/tcp/50214/http"
   2315 "/dns/148.153.188.172/tcp/45382/http"
   4153 "/dns/148.153.245.20/tcp/38965/http"
   2348 "/dns/42.125.245.71/tcp/61047/http"
     82 "/ip4/113.23.169.21/tcp/53002"
     77 "/ip4/113.23.169.21/tcp/53004"
   4147 "/ip4/14.238.44.27/tcp/13003"
   2315 "/ip4/148.153.188.172/tcp/30002"
   4153 "/ip4/148.153.245.20/tcp/13004"
   2348 "/ip4/42.125.245.71/tcp/30001"

Many contextIDs:

$ curl -s https://cid.contact/cid/QmeLvFK9dBLhC3kbfc58mLntUei6s7fZUGWsm1xJhczm1S | jq '.MultihashResults[].ProviderResults[].ContextID' | sort | uniq | wc -l
13122

Most likely 2 entries per contextID for both graphsync and http.

[willscott]

• it could be they have the same piece a lot of times?
• we could submit updates to the provider library in curio to be more efficient in de-duping, since there isn't any of that currenlty

[lidel]

When queried through kubo node, object is reported as not found.

This is expected. Every record returned by cid.contact for QmeLvFK9dBLhC3kbfc58mLntUei6s7fZUGWsm1xJhczm1S is unreachable from modern IPFS clients, and on top of that the response size trips the 1 MiB safety limit in Kubo before any record is even parsed.

Below are the overlapping issues that produce this symptom. Any one of them would be enough to break retrieval, and here we manage to hit all of them at once ;-)

Jump to 👉 ️TLDR if in a rush.

cid.contact returns 14k providers as >4 MiB of JSON

Kubo performs lookups via the /routing/v1 API (https://specs.ipfs.tech/routing/http-routing-v1/). The spec says application/json responses SHOULD be limited to 100 results, with the streaming application/x-ndjson path available for more. Kubo asks for NDJSON, but cid.contact does not implement it and always responds with application/json, regardless of the Accept header.

The provider lookup URL is https://cid.contact/routing/v1/providers/QmeLvFK9dBLhC3kbfc58mLntUei6s7fZUGWsm1xJhczm1S and the result is a single ~4.28 MiB JSON blob with 14k provider records:

Protocol	Count	Usable by IPFS go-ipfs Kubo?
transport-graphsync-filecoinv1	14,092	No. Dead protocol.
transport-ipfs-gateway-http	6	No. Misconfigured (plain HTTP).
transport-bitswap	0	n/a

Kubo (via boxo/routing/http/client) applies a hard LimitBytes of 1 MiB cap on the response body. At 4.28 MiB this CID's response trips the cap and the JSON decode errors out before a single record is parsed. Kubo never even gets to filter the 14k records locally. One bug masks the other.

Graphsync is a dead protocol

Experimental Graphsync support was removed from Kubo in 2023 (ipfs/kubo#9747) and from the IPNI tooling in 2025 (ipni/ipni-cli#126). AFAIK no non-Filecoin IPFS client can retrieve data over transport-graphsync-filecoinv1 anymore.

Why these 14k records still show up in 2026 is a question for the Filecoin / cid.contact side. I'm not familiar enough with IPNI internals to say whether it is a legacy ingestion path, SPs continuing to announce, or something else.

Cleartext HTTP (no TLS) addresses are also ignored

All 6 transport-ipfs-gateway-http entries advertise plain HTTP/1 over TCP:

/dns/14.238.44.27/tcp/50214/http
/dns/148.153.245.20/tcp/38965/http
/dns/148.153.188.172/tcp/45382/http
/dns/42.125.245.71/tcp/61047/http
/dns/113.23.169.21/tcp/55418/http
/dns/113.23.169.21/tcp/51094/http

The Trustless Gateway spec (https://specs.ipfs.tech/http-gateways/trustless-gateway/#p2p-transport) says HTTPS and HTTP/2 SHOULD be used for non-LAN transport-ipfs-gateway-http. None of these addresses have a /tls/ or /https component, so IPFS clients will not dial them.

FWIW I flagged this same class of misconfiguration in the Filecoin SP ecosystem last year in CheckerNetwork/spark-checker#137. That monitoring project was shut down and the repo archived instead of the SP side getting fixed 🙃 Make of that what you will.

IPIP-484 filters are ignored too

Kubo already asks cid.contact to filter server-side via IPIP-484:

GET /routing/v1/providers/QmeLv...?filter-protocols=unknown,transport-ipfs-gateway-http,transport-bitswap

cid.contact silently ignores this filter and returns the full set:

$ curl -s 'https://cid.contact/routing/v1/providers/QmeLv...?filter-protocols=transport-bitswap' \
    | jq '.Providers | length'
14098

Kubo runs defense-in-depth: it asks the server to filter, and still filters locally as a precaution. Our belt-and-suspenders approach paid off here, because without the 1 MiB cap and the local filter Kubo would try to dial 14k dead peers with no diallable endpoints ;-)

👉 ️ TL;DR

Kubo requests cid.contact data, hits the 1 MiB response cap, and (even if the response fit) local filtering would drop every single record (graphsync removed, plain HTTP not dialable). Not one result contains actionable provider information. The CID may still be retrievable directly from Filecoin SPs over Graphsync or cleartext HTTP, but that path is necromancy and is not exposed to modern IPFS clients like Kubo.

Suggested fixes

There are two independent problems here:

1. Fix HTTPS retrieval on the SP side. HTTP providers need PKI TLS with HTTP/2, with multiaddrs updated to /tls/http or /https. Without that, no modern IPFS client will touch them.
2. Fix the 4 MiB response on the cid.contact side. At minimum, cap application/json at 100 results (or anything under 1 MiB) per spec. On top of that, either:
   • (A) implement IPIP-484 filter-protocols on /routing/v1/providers so clients can ask the server to drop the long tail of useless graphsync records before it is serialized, or
   • (B) prioritize HTTP/Bitswap providers in the first 100 results served over application/json, so there is at least a non-zero chance of finding an actionable record within spec limits.

Implementing application/x-ndjson streaming would also help, so clients that explicitly ask for it can page through more than 100 results (up to 1MiB of them) instead of receiving a truncated list, but for databases like IPNI ("it is fast to return all results, no need for streaming") it may be more cache-efficient to always return JSON. So just keep it under 1 MiB at least. Something smaller would be better (100 results) because browser / mobile client should not fetch 1MiB to open 100 KiB JPG etc ;-)

Hope this helps.

[byo]

@lidel can you take a look at ipni/indexstar#234 ? That's a first step to make the routing endpoint more reliable - that PR implements filters + caps the json response to 100 entries.