scout

A light, no-node client for reading content from Swarm. Point it at a public gateway (or any Bee HTTP endpoint) and fetch content by reference — no node to run, no stake, no postage batch. The "scout bee" that finds and fetches without keeping the hive.

Published on crates.io as swarm-scout (the binary and library are both scout).

Install

cargo install swarm-scout      # provides the `scout` command

Usage

# read — no node, stake, or stamp
scout cat   <ref> [path]        # print content to stdout (manifest-aware, /bzz)
scout get   <ref> <out> [path]  # download content to a file
scout bytes <ref>               # print the raw bytes behind a reference (/bytes)

# write — needs a Bee node holding a postage batch
scout up       <file> [--name n] --stamp <batch>   # upload a file (/bzz)  -> ref
scout up-bytes <file>            --stamp <batch>    # upload raw bytes (/bytes) -> ref

# feeds — a stable handle that always serves the latest content
scout keygen                                              # identity (key + owner + pubkey)
scout publish <ref> --key <hex> -t <topic> --stamp <batch>   # -> feed manifest ref
scout cat <feed-manifest-ref>                            # read latest (re-publish to update)

# sharing — encrypted + revocable (Access Control Trie)
scout share <file> --to <pubkey> --stamp <batch>         # -> file_ref / history / publisher
scout fetch <file_ref> --publisher <pk> --history <h>    # decrypt (as publisher/grantee)
scout grantees --grantee-ref <r>                         # who has access
scout revoke --grantee-ref <r> --history <h> --grantee <pk> --stamp <batch>

The read endpoint comes from --gateway / $BEE_GATEWAY (default http://localhost:1633). Uploads go to --node / $BEE_NODE (defaults to the gateway) and require --stamp / $BEE_STAMP (a usable postage batch):

scout --gateway https://your-gateway.example cat <ref>
scout --node http://localhost:1633 up photo.jpg --stamp <batch>   # -> reference
BEE_NODE=http://localhost:1633 BEE_STAMP=<batch> scout up notes.md

Why "light"?

Reads (/bzz, /bytes) are served by any gateway or remote Bee — no local node, stake, or stamp required. That's the light-node idea: most people who use Swarm just want to fetch (and, later, share) content, not operate infrastructure.

Feeds (mutable pointers)

A feed gives you a stable reference that always serves the latest content — the basis for "a folder/site whose contents change but whose link doesn't."

scout keygen                                   # save the key; note the owner
scout publish <ref> --key <key> -t mysite --stamp <batch>   # prints a feed manifest ref
scout cat <feed-manifest-ref>                  # serves the latest published content
# publish again under the same key+topic → the same manifest ref now serves the new content

Sharing (ACT)

Encrypted, revocable sharing via Swarm's Access Control Trie. share uploads a file encrypted and grants a set of recipient compressed pubkeys (scout keygen prints one); recipients download with the file_ref + publisher + history. revoke drops a key without re-uploading.

scout keygen                                              # note the pubkey
scout share secret.pdf --to <recipient-pubkey> --stamp <batch>
scout fetch <file_ref> --publisher <pubkey> --history <h> out.pdf
scout revoke --grantee-ref <r> --history <h> --grantee <pubkey> --stamp <batch>

A recipient decrypts on their own Bee node (configured with the key behind their pubkey); the node does the decryption, so fetch works for whoever's node it runs against (the publisher always; a grantee on theirs).

Status

• Read — cat / get / bytes; no node, stake, or stamp.
• Write — up / up-bytes to a Bee node holding a postage batch.
• Feeds — keygen / publish; read the latest via cat.
• Sharing (ACT) — share / fetch / grantees / revoke.
• All verified end-to-end against a live Bee node (2.7.2).
• Next: a friendlier share registry (track shares by id) and the swarm-drive end-user tool on top.

Built on bee-rs.

License

MIT