Sparse replication

A sparse receiver stores authenticated metadata and only the payload blocks it requests. Knowing the logical length of a strand does not mean every block is present. The receiver verifies data under the writer key and retains its cache across restarts.

Producer and consumer

Follow the first-strand quickstart to create, append and announce on the producer. Keep that node online. On the consumer, use the producer's writer_pubkey and a fresh local alias. For a strand containing at least eight blocks:

WRITER_PUBKEY='REPLACE_WITH_THE_64_HEX_WRITER_PUBLIC_KEY'
~/.weave/bin/weave strand replicate shared-feed --source-pubkey "$WRITER_PUBKEY" --sparse --blocks 7 --wait-secs 30 --json
~/.weave/bin/weave strand read shared-feed --start 7 --length 1 --json

The alias can differ from the producer's local name because discovery is keyed by the writer public key. If you previously used dht find to pin that key as shared-feed, reuse that alias. The native store keeps one local pin for the same key; do not try to create another with --target under a different name.

Without --blocks, sparse replication requests and verifies block 0. An empty announced strand can be found, but cannot satisfy a block-0 replication request until the writer appends data. --blocks 0-3,7 requires those indices to exist. A request fails if any selected block cannot be verified before its deadline.

Fetch another block later

~/.weave/bin/weave strand read shared-feed --start 2 --length 1 --json

The read fetches the missing block through a live authorized provider session. Already verified blocks can be read from the cache. The pin stays read-only; it does not acquire the producer's signing key or authority to announce a new writer lease.

Read the result accurately

blocks_present counts cached payload blocks; logical_blocks describes authenticated strand length. verified_block_reads counts successfully verified reads in this operation, including cached data. For selected ranges, block_stats distinguishes transferred, skipped/cached and failed requests. The SDK does not expose authoritative per-block serving-peer attribution, so the CLI reports that limitation rather than inferring a peer from session order.

A successful find, a connected peer, metadata alone, or a local writer's cached_local response does not prove a remote transfer. Verify a consumer's returned bytes. The cross-machine quickstart does this explicitly.

Full replication

On a consumer, omit --sparse and --blocks to fetch and verify the authenticated current snapshot:

~/.weave/bin/weave strand replicate shared-feed --source-pubkey "$WRITER_PUBKEY" --wait-secs 30 --json

A failed full request retains verified local data and can be rerun to resume. This operation verifies the sampled snapshot; it does not promise an indefinite tailing subscription. On an existing local writer, the non-sparse command announces/seeds its own data rather than proving a download.

Limits and connectivity

The native append limit is 256 KiB per block. Reads are limited to 128 blocks and 256 KiB of combined content per response. The CLI and MCP discovery/replication wait is bounded to 30 seconds; network/bootstrap and subprocess work have separate bounds.

The runtime supports authenticated libp2p relay streams and direct transport. Public relays impose their own circuit limits. A public relay's budget may be smaller than the runtime's maximum block size once handshake and protocol overhead are included; this release does not promise maximum-size block transfer through every public circuit. Use small blocks for the public-seed walkthrough; large public transfers require a route with sufficient capacity. A local relay test with a larger budget does not change a public relay's quota.

Writer keys authenticate signed blocks; they are public discovery inputs, not a secrecy or account-login mechanism. Publish only data you intend reachable peers with the key to request.