Fetch CAS blobs over Iroh

README.md

@@ -91,8 +91,8 @@ The bootstrap implementation provides:
 - `geth auth explain <subject> <resource> <capability>`
 - `geth auth grant <subject> <resource> <capability> [--grant-id <id>]`
 - `geth auth revoke <resource> <grant-id>`
-- local filesystem CAS commands: `add`, `get`, `hash`, `has`, `pin`, `unpin`,
-  `cleanup`, `list`
+- local filesystem CAS commands: `add`, `get`, `fetch`, `hash`, `has`, `pin`,
+  `unpin`, `cleanup`, `list`
 - local CAS tree objects describe file trees and are stored as CAS blobs
 - local file-root commands: `geth cas root add/list/scan`
 - local file conflict metadata commands:
@@ -125,6 +125,12 @@ imported peer card and exchange a signed candidate-only peer-card ping.
 `geth peer auth-check <node-id> <resource> <capability>` sends a protected
 Iroh control request: the remote daemon verifies that the caller's signed peer
 card binds the actual Iroh EndpointID before reducing resource-local auth ops.
+`geth cas fetch <node-id> <hash>` uses the same protected Iroh control path to
+request a blob from a peer. The remote daemon only returns bytes when the caller
+has `cas.fetch` on `resource:cas:local`, and the caller verifies that the bytes
+hash to the requested BLAKE3 CAS hash before storing them locally. This is the
+bootstrap transfer path; future work will move provider/fetch behavior to
+`iroh-blobs`.
 Importing or pinging a peer card never grants capabilities by itself.
 When `[iroh].local_discovery = true`, the daemon also advertises and discovers
 signed peer cards on LAN using a geth-specific mDNS TXT payload. That payload is