bee-check 0.6.0

Retrievability checker for Ethereum Swarm references. Multi-vantage stewardship probes, per-chunk drill-down, and one-shot re-seed.
Documentation
# Comparison to `check.ipfs.network`

`bee-check` is the Swarm analog of
[`check.ipfs.network`](https://check.ipfs.network/) — IPFS's
retrievability checker. They solve the same problem on different
protocols.

## Feature-by-feature

| Capability | `check.ipfs.network` | `bee-check` (CLI) | `bee-check-web` (SPA) |
|---|---|---|---|
| Single retrievability probe ||`GET /stewardship/{ref}` ||
| Mutable-name resolution | ✅ IPNS / DNSLink |`feed:OWNER:TOPIC` ||
| Multi-vantage / multi-peer | ⚠️ one Multiaddr field |`--bee` repeats | ✅ one URL per line |
| Gateway probe | ⚠️ optional HTTP retrieval |`--gateway` repeats | ✅ one URL per line |
| Per-block / per-chunk drill-down ||`--per-chunk` | ✅ checkbox |
| Per-vantage latency ||`elapsed_ms` + p50/p95/max | ✅ same stats |
| Neighborhood / proximity context | partial (DHT advert check) | ✅ overlay + PO + `--target-overlay` ||
| Node identity in report || ✅ overlay + version ||
| Per-chunk matrix view || ✅ JSON | ✅ table |
| JSON export / shareable report ||`--output json` | ✅ Show JSON + drop-to-render |
| Shareable diagnostic link |||`?ref=…&bee=…` |
| Active repair (re-seed / re-pin) ||`--reseed` | ✅ panel with pre-flight gate |
| Stamp pre-flight before repair | n/a |`check_stamp` ||
| Progress feedback during long probes || implicit | ✅ "Probing N/M…" |
| Direct libp2p Multiaddr dial || ❌ HTTP-only ||
| DHT advertisement record check || ❌ uses stewardship as proxy ||
| ENS / DNSLink-equivalent || ❌ feeds only | ❌ feeds only |

## Where they differ in mechanism

- **DHT vs stewardship.** `check.ipfs.network` asks "is this CID
  advertised in the DHT, and can the storing peer be reached?" —
  it inspects the routing layer directly. `bee-check` doesn't have
  a Swarm-DHT analog to inspect; instead it asks a Bee node "can you
  retrieve this through the network?" which is a higher-level
  signal but covers the same ground (a chunk that isn't reachable
  also wouldn't satisfy a stewardship retrieve).
- **HTTP vs libp2p.** Everything `bee-check` does goes through Bee's
  HTTP API. There is no direct peer-to-peer dial. The cost is one
  layer of indirection; the benefit is no libp2p stack in your
  toolchain and no need to operate a peer.

## What's still in IPFS-check's column

Three things `check.ipfs.network` does that `bee-check` doesn't:

1. **Direct libp2p Multiaddr dial.** Asks "can I, the checker, talk
   to this specific peer right now?" Swarm equivalent would be a
   Bee-to-Bee health check that doesn't exist as a public API.
2. **Inspect the DHT routing record directly.** Swarm doesn't
   expose its routing layer the way libp2p Kademlia does.
3. **ENS / DNSLink-style naming.** Both could be added to
   `bee-check` (ENS would need a JSON-RPC client + namehash + the
   ENS resolver contract); it just isn't there yet.

If any of these matter for your workflow, file an issue.