Expand description
The blob route of decdn get (decdn:<hash>): the 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
decdn_incentive::buyer_pool_redb::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.
Discovery, lane building and pool funding are decdn-client’s engine
seams ([decdn_client::targets], [decdn_client::lanes],
[decdn_client::funding], [decdn_client::lane_sources]), which
the bundle route (super::bundle_pull) drives too. This module resolves the command’s flags
and config into their inputs, and renders what the fetch did.