Expand description
decdn fetch — standalone client-side paid pull of a single
content-addressed blob over cdn/client/v1 (issues #391, #940).
Turnkey paying sibling of super::probe: dial a node by explicit
--node-id/--addr/--relay-url (or auto-discover the holders, #936),
auto-open-or-reuse the caller’s own PaymentPool deposit, take the
first size claim (the probe hint, or a header-only open when there is
none), and fetch it through the acquire loop
(decdn_client::acquire) across one decdn_client::PeerSource lane
per holder (signing cumulative vouchers, resuming each lane’s persisted
watermark, verifying the slash_sig recovers to the provider, ADR 014 §1).
Every byte is bao-verified; each lane’s new watermark is persisted, and the
file is promoted atomically. A holder that faults cools and returns; the
command ends on done, a fault only the user can fix, or the stop policy.
Pool lifecycle: the caller’s live pool in the persistent
RedbBuyerPoolStore is reused (the (signer, provider) lane watermark is
resumed) — and topped up on-chain via topUp (best effort) when its
pool-wide remaining deposit has run low, so a sustained series of fetches
isn’t stranded;
otherwise one is opened on-chain (USDC approve if needed → openPool) via
the shared decdn_client::buyer_pool::open_pool kernel and recorded.
One pool fans out to every provider the caller pays (ADR 003) — there is no
per-provider open. The chain coordinates resolve flag >
[blockchain]/[identity] config > default.
The chain/discovery/delivery seams (resolve_chain, resolve_target_node,
probe_and_order, open_or_reuse_pool, build_multi_lane/DriveFetchDeps,
temp_in_parent) are pub(crate) so decdn bundle pull (#391) reuses the
same acquire loop and funding recovery across a bundle’s many entries.
Functions§
- fetch
- Fetch a single blob over
cdn/client/v1, auto-opening/reusing the caller’sPaymentPooldeposit, and write it atomically to--output.config_path(the global--config) supplies relays (#935), discovery (#936), and chain coordinates.