bee-check 0.5.0

Retrievability checker for Ethereum Swarm references. Multi-vantage stewardship probes, per-chunk drill-down, and one-shot re-seed.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

# Swarm references vs IPFS CIDs

A **Swarm reference** is a 32-byte address (rendered as 64 hex chars,
or 128 hex chars for the encrypted variant) that identifies content
in the Swarm network. It looks like:

```
c79394a6c311f816373ec9945365325e7fc0784cfa9a62deec1524d2c2bdc36a
```

`bee-check` accepts that hex string with or without a `0x` prefix.

## How it differs from an IPFS CID

A reference is content-addressed like a CID, but the resemblance ends
there:

| | Swarm reference | IPFS CID |
|---|---|---|
| Hash function | BMT-keccak256 (Binary Merkle Tree) | configurable; usually sha2-256 |
| Encoding | raw hex | multibase + multihash + codec |
| Self-describing | no — the bytes don't tell you the hash function | yes — the multihash prefix does |
| Length | 32 bytes (64 hex), 64 bytes (128 hex) for encrypted | variable |
| Mutable equivalent | **Swarm feed** (`feed:OWNER:TOPIC`) | IPNS / DNSLink |

The practical consequence is that you can't tell from the bytes alone
whether a reference points to a raw chunk, a manifest (file or
directory), or a feed update. `bee-check` will try to walk it as a
manifest when you pass `--per-chunk`; if that fails, it falls back to
treating it as a single chunk.

## Mutable references — feeds

Swarm feeds are the analog of IPNS/DNSLink. A feed is identified by
an `(owner, topic)` pair:

- `owner` — a 20-byte Ethereum address (40 hex chars)
- `topic` — a 32-byte hash (64 hex chars)

`bee-check` accepts feed inputs as `feed:OWNER:TOPIC` or
`feed:OWNER/TOPIC` and resolves them via `GET /feeds/{owner}/{topic}`
on the first `--bee` URL before probing. The resolved chunk reference
becomes the report's top-level `reference`, and the original
(owner, topic) is preserved under `resolution`.

> **Note:** Feed resolution only goes one level deep. If the feed
> points at *another* feed, you'd need to resolve that one separately.
> In practice this never comes up because feed payloads are normally
> manifest references, not other feeds.

## See also

- [Swarm docs — Content addressing](https://docs.ethswarm.org/docs/concepts/data/chunks)
- [Swarm docs — Feeds](https://docs.ethswarm.org/docs/develop/access-the-swarm/feeds)
- [Bee API — `GET /feeds/{owner}/{topic}`](https://docs.ethswarm.org/api/#tag/Feed)