**Note** from Bead: Create Webdav Server · [canonical source](https://redfish.acequia.io/guerin/.agents/a0a6f25a-53ef-4fd5-bfc8-a4b982420312/2026-06-18/notes/03-phase-2-acequia-participation.md) · session 2026-06-18 · discussion: Talk: Create Webdav Server
*Roadmap placeholder, captured 2026-06-18 from Stephen so the direction is not lost. Phase 1 (this bead so far) is "stand up a WebDAV server on any runtime." Phase 2 is "make that server a **participant** in acequia," i.e. join the peer mesh and the shared auth/state model, not just answer WebDAV verbs. Detailed instructions to follow; this note frames the shape.*
## The frame A WebDAV server from Phase 1 is a plain origin. An **acequia participant** additionally speaks the acequia client protocol: chain-token auth, group/peer discovery, WebRTC connectivity, and the Plan9-ish `/acq/` routing. The two client halves come from the `acequia2` sibling repo (see the config-model note [`02`](https://redfish.acequia.io/guerin/.agents/a0a6f25a-53ef-4fd5-bfc8-a4b982420312/2026-06-18/notes/02-nephele-config-model.md)): - **`acequia.js`** — the `window.acequia` client library (IndexedDB key/wallet, chain signing + `resolveAndVerify`, groups, route matching, WebRTC). Loaded in a page to make it a parciante node. - **`acequia-sw.js`** (the built service worker, `sw.js` in the repo) — route matching, `/acq/` VFS mounts, and the WebRTC proxy. This is what lets **BrowserDAV** (bead [`bb39886e`](https://redfish.acequia.io/guerin/.agents/bb39886e-f0bc-48d5-9b4e-23e4b8a457b7/about.md)) serve WebDAV from a tab and reach peers.
## Two participation recipes to write (Phase 2) 1. **Participate from a page with `acequia.js`** — drop `acequia.js` in the page, init the client, register/adopt a key, join a group, and address peers and `/acq/` mounts. Turns any of the Phase-1 runtimes (or a static page) into a parciante that can carry chain tokens and reach the mesh. 2. **Serve from the browser with `acequia-sw.js` + `acequia.js` (BrowserDAV)** — register the service worker, mount a File System Access / OPFS directory, and answer WebDAV in-page with the same chain-token model as the node server. The browser becomes a first-class WebDAV **origin** and peer. Both will follow the Phase-1 recipe contract (when/prereqs · install · serve · auth · CORS · verify · gotchas · status) and point auth at the chain-token model in [`9b2fcc1c`](https://redfish.acequia.io/guerin/.agents/9b2fcc1c-8960-49fb-ab6d-28b331a4e179/about.md).
## Later (discussed, not scheduled): OPFS + named caches synced across an origin's endpoints A further direction Stephen flagged: use **OPFS** and **named caches** (Cache API) as the local store, and **sync those caches across the endpoints of a given origin** — the several nodes that serve the same logical paths (node origin, browser SW, tunnels, peers) holding the same named-cache state, kept coherent. This is the decentralized-cache-management substrate (bead [`4456cd24`](https://redfish.acequia.io/guerin/.agents/4456cd24-010a-41e9-a14c-a2d1086893bd/about.md)): "the cache IS the state," each replica a peer. Phase 2's BrowserDAV (OPFS-backed) is the concrete local store this would sync. No design committed yet; flagged here as the next horizon.
## Where it lands These become two new skills under this bead's `skills/` (e.g. `acequia-participate-page/` and `browserdav-acequia/`), new rows in the runtime matrix and `webdav-installer-mcp/recipes.json`, and new cards in `install.html` — consistent with the bead being an active document that "grows to host more of the platform." The OPFS/named-cache sync work, if pursued, likely belongs partly here (the BrowserDAV store) and partly in `4456cd24` (the sync substrate).
## Open questions to resolve when Phase 2 starts - Exact `acequia.js` / `acequia-sw.js` init surface and where the built bundles are served from (the repo ships them in `localWebDAV/public/`; a participant page needs a stable URL for them). - Key custody on a participant page (per [`feedback_browser-is-a-parciante-node`] — scope × blast radius × revocability, not a blanket "no keys in the browser"). If a participant binds cloud cognition, it is an **Anthropic API key** (BYOK), not a Claude subscription — see [`notes/04-anthropic-eula-cognition.md`](https://redfish.acequia.io/guerin/.agents/a0a6f25a-53ef-4fd5-bfc8-a4b982420312/2026-06-18/notes/04-anthropic-eula-cognition.md). - Whether the step (`webdav-step`) gains a participation verb (e.g. `join_group`) or stays rung-0. - The named-cache sync wire format / transport — defer to `4456cd24`.
## References (bead cross-links) - Bead: BrowserDAV · [canonical](https://redfish.acequia.io/guerin/.agents/bb39886e-f0bc-48d5-9b4e-23e4b8a457b7/) - Bead: Acequia Authorization · [canonical](https://redfish.acequia.io/guerin/.agents/9b2fcc1c-8960-49fb-ab6d-28b331a4e179/) - Bead: Decentralized Cache Management · [canonical](https://redfish.acequia.io/guerin/.agents/4456cd24-010a-41e9-a14c-a2d1086893bd/)