Downstream interest + independent evaluation (BMT/SOC verified against live 2.8.1) — maintenance status?

[petfold]

Hi @martinconic — thanks for this. I run a few small Swarm-on-Python projects (recordstore, swarmfs, ontodag) and, while looking at how to give them a Bee client, found swarm-bee. We did a fairly thorough independent evaluation before considering a dependency, and I wanted to share the results and ask about your plans.

What we checked (all passing):

• Full offline test suite — 431 tests green.
• Live round-trips against a Bee 2.8.1 light node on Gnosis mainnet: /bytes (small + multi-chunk split), raw /chunks, chain_state, stewardship, and a client-side-signed feed/SOC update.
• The decisive one for us — the client-side BMT chunk address matched the node's independently-computed address byte-for-byte, so the BMT/CAC implementation is verifiably correct, not just plausible. SOC signing and the mantaray wire format also check out on read.

Honestly, the crypto core is good enough that we'd rather depend on it than reimplement it.

Two things we noticed:

1. The version pin targets Bee 2.7.2-rc1 / API 8.0.0; 2.8.1 (API 8.1.0) added a couple of small endpoints not yet covered client-side — GET /batches/{batch_id} and PATCH /stamps/{batch_id} — plus some new response fields (e.g. minimumValidityBlocks on /chainstate). Everything still works against 2.8.1; is_supported_api_version() just returns False on the exact-string check.
2. There are no issues/PRs yet, so we couldn't gauge how actively you're maintaining this vs. your upstream ethersphere/bee work.

Questions:

• Is swarm-bee something you intend to keep current with Bee releases, and are you open to issues/PRs on it?
• If so, we'd be glad to contribute back — e.g. a PR for the 2.8.1 endpoint/field catch-up — rather than just consume it.

Either way, thanks for building this (and bee-go/bee-rs — nice to see the parity claim is literally true). Starred and watching.