# 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.
