**Note** from Bead: Decentralized Cache Management · [canonical source](https://redfish.acequia.io/guerin/.agents/4456cd24-010a-41e9-a14c-a2d1086893bd/2026-06-14/notes/11-webdav-bead-browserdav-and-signed-ledger.md) · session 2026-06-14 · discussion: Talk: Decentralized Cache Management
*Bead `4456cd24` · 2026-06-15 · Stephen's auth-plane move. Generalizes the URI face of [04](04-computed-resources-agent-face-in-sw.md) to full WebDAV; makes the ledger of [07](07-cache-entry-as-wheeler-feynman-transaction.md)/[08](08-anticipatory-caching-advanced-wave-operational.md) signed; engages bead-as-webdav-handler and token-minting-pattern.* > Stephen: **"consider webdav-bead and browserDAV where authentication and token is handed in the acequia.js and serviceworker. and cache request has auth-token."**
## browserDAV — the URI face, generalized to the full WebDAV verb set Note 04 served the URI face for GET (file), PROPFIND (folder), OPTIONS (agent). **browserDAV** implements the **whole WebDAV verb set in the SW** over the local stores: | Verb | browserDAV action over local stores | |---|---| | `GET` | serve from Cache face (note 03/04) | | `PUT` | write to OPFS engine, materialize into Cache face (note 05/09) | | `PROPFIND` | list the local namespace (computed folder face) | | `MKCOL` | create a collection | | `MOVE` / `COPY` | rebind within the local namespace | | `DELETE` | apoptotic eviction (note 00) | | **`LOCK` / `UNLOCK`** | **the lease / leader-election primitive — for free from the protocol** (note 00 authority axis, note 01 CP path) | The consequence is **protocol uniformity**: the browser becomes a **peer WebDAV origin**, not a client of one. One WebDAV client in `acequia.js` talks to the browser SW exactly as it talks to the loopback (note 02) or a remote acequia endpoint. So "write once, run at every tier" (note 10) extends from the *merge code* to the *wire protocol* — every rung of the mount-stack (note 05) and tier-hierarchy (notes 09/10) speaks WebDAV. Sync between browser and remote becomes WebDAV ↔ WebDAV, the browser a peer rather than only a pusher. **webdav-bead** is then the bead-as-webdav-handler (bead-as-webdav-handler `fe7fbaf5`) realized: a bead *served as a WebDAV origin*, with the agent-face function (note 04) sitting behind the verbs. browserDAV is how a webdav-bead runs in the browser.
## acequia.js + SW as the auth plane - **`acequia.js`** = the in-page SDK (note 10's L1/page tier; the Firebase-SDK analogue). Holds the signing key / chain-token; **mints attenuated, cascade-revocable sub-tokens** per scope (token-minting-pattern). - **Service worker** = **ambient auth**: injects the token into outgoing + subresource/worker/wasm requests so each consumer does not re-handle auth. - Placement is per scope × blast-radius (browser-is-a-parciante-node): page tier mints, SW tier injects, neither hard-codes a broad bearer.
## "cache request has auth-token" → the ledger is signed The cached **Request** carries `Authorization: Bearer <chain-token>`. So note 07's **debit leg now records who, under what delegated capability, non-repudiably** — not just *what* and *when*. That is exactly what makes note 07's **prorrata open thread computable**: every draw is a signed, attributable record, so "return in proportion to draw" has a real quantity to sum over. The advanced-wave accounting (note 08) gains a cryptographic identity column; attention/reputation/wealth owed back is now attributable to a specific parciante and capability chain.
## Two honest flags (auth + cache is a known footgun) ### 1. The token must partition the cache, or it leaks across principals By default the Cache API **matches by URL and ignores `Authorization`** — so principal A's cached Response can be served to principal B hitting the same URL. The fix turns note 02's "named caches per origin" into **named caches per principal / capability**: the auth-token selects *which* cache partition the entry lives in. So the token does **triple duty**: 1. **ledger "who"** (note 07) — the debit identity, 2. **cache-partition key** — which named cache the entry lives in, 3. **per-caller namespace view** — which bound subtree this principal sees (uri-bind-mount, Plan-9 per-process namespace). Auth, partitioning, and namespace composition **collapse into one thing**: the token *is* the principal's view of the commons. (A private dir = absence of a `read:anonymous` partition.) ### 2. Credentials-in-cache has a blast radius Persisting raw tokens inside cached Requests in OPFS means a compromised device leaks them. Mitigations, pick per resource class: - **short-TTL apoptotic tokens** (note 00) — the credential self-expires; - **store a token *reference*** (principal-id / capability handle), not the secret; - **inject at serve-time** — cache only URL + principal-id; the SW re-signs on replay rather than storing the live token in the cached Request. Which of these *is* the meaning of "cache request has auth-token" is a design decision to pin (likely inject-at-serve for hot paths, reference-store for durable entries).
## Open threads - **Token-as-namespace** — formalize the token → bound-namespace-view mapping; one resource, different local names/visibility per token (the per-caller `names.json`, note's own bead carries one). - **LOCK semantics across tiers** — does WebDAV LOCK serve as the lease for tab↔tab (note 10) *and* node↔node (note 00) leader-election? One lock model at every scale would match the fractal claim. - **Token TTL vs batch window** — the apoptotic token lifetime (note 00) must outlive the write-back batch window (note 09) or a flush can fail auth mid-settle. - **PROPFIND scope enforcement** — browserDAV's folder face must filter by the token's read scope; listing is capability-shaped, not raw.