Summary
Live measurement on the `unicity-ipfs1.dyndns.org` kubo container on 2026-05-29 showed the sidecar's instant-pin cache at 9,995 of 10,000 entries while only consuming 90 MB of its 1 GiB byte budget. The entry-count cap is the binding constraint, evicting recently-submitted blobs that wallets later try to fetch — producing ~33,405 `GET /sidecar/blob?cid=… 404` responses per 6 hours observed in container logs. Cache hit rate is only 3.3 %.
Proposed change
Bump `SIDECAR_CACHE_MAX_ENTRIES` from `10_000` to `100_000`. Memory budget remains adequate: ~9 KB average per cached entry × 100 k entries = ~900 MB, well within the existing 1 GiB `SIDECAR_CACHE_MAX_BYTES` cap.
Where it's set
- `docker-compose.yml` line 72: `SIDECAR_CACHE_MAX_ENTRIES=${SIDECAR_CACHE_MAX_ENTRIES:-10000}`
- `Dockerfile` line 106: `SIDECAR_CACHE_MAX_ENTRIES="10000"`
- `nostr-pinner/instant_pin_cache.py:657`: `max_entries=int(os.getenv("SIDECAR_CACHE_MAX_ENTRIES", str(DEFAULT_MAX_ENTRIES)))`
Default is fine to bump in all three places; the env-var override path (compose / run-ipfs.sh) is unchanged.
Verification
Before/after:
```bash
curl -s https://unicity-ipfs1.dyndns.org/sidecar/cache-stats | jq '{confirmed: .confirmed_entries, max: .max_entries, bytes_used: .bytes_used_total, bytes_max: .max_bytes, miss_rate: (.cache_misses / (.cache_hits + .cache_misses))}'
```
Expected: `max_entries` rises to 100000; `miss_rate` drops from ~0.97 toward the byte-budget limit.
Context
This is one of three distinct problems contributing to the wallet page freeze investigated 2026-05-29. The other two are wallet-side:
- Deprecated `IpfsStorageProvider` chain-break retry loop — fixed in `unicity-sphere/sphere#326`
- Sidecar's blocking DHT fallback returning 500 on timeout — separate issue, possibly tracked under the kubo DHT-provider tuning
- This issue — the 4xx floor in the browser console that scares operators even when nothing's actually wrong
Disk free on the host is currently 501 GB so disk pressure is not a constraint. The kubo container itself is healthy (`Up 4 days (healthy)`, all live probes `200`).
Summary
Live measurement on the `unicity-ipfs1.dyndns.org` kubo container on 2026-05-29 showed the sidecar's instant-pin cache at 9,995 of 10,000 entries while only consuming 90 MB of its 1 GiB byte budget. The entry-count cap is the binding constraint, evicting recently-submitted blobs that wallets later try to fetch — producing ~33,405 `GET /sidecar/blob?cid=… 404` responses per 6 hours observed in container logs. Cache hit rate is only 3.3 %.
Proposed change
Bump `SIDECAR_CACHE_MAX_ENTRIES` from `10_000` to `100_000`. Memory budget remains adequate: ~9 KB average per cached entry × 100 k entries = ~900 MB, well within the existing 1 GiB `SIDECAR_CACHE_MAX_BYTES` cap.
Where it's set
Default is fine to bump in all three places; the env-var override path (compose / run-ipfs.sh) is unchanged.
Verification
Before/after:
```bash
curl -s https://unicity-ipfs1.dyndns.org/sidecar/cache-stats | jq '{confirmed: .confirmed_entries, max: .max_entries, bytes_used: .bytes_used_total, bytes_max: .max_bytes, miss_rate: (.cache_misses / (.cache_hits + .cache_misses))}'
```
Expected: `max_entries` rises to 100000; `miss_rate` drops from ~0.97 toward the byte-budget limit.
Context
This is one of three distinct problems contributing to the wallet page freeze investigated 2026-05-29. The other two are wallet-side:
Disk free on the host is currently 501 GB so disk pressure is not a constraint. The kubo container itself is healthy (`Up 4 days (healthy)`, all live probes `200`).