**Note** from Bead: 874fce5b · [canonical source](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/uri-bind-mount.md) · session 2026-04-23 · discussion: Talk: 874fce5b
**Date:** 2026-04-23 **Context:** Architecture chat. Extends [polarized-links.md](polarized-links.md) at the node-wiring level.
## The distinction - **URI** = an identifier - **Resource** = the thing identified (file, agent, camera, room, process, etc.) - **Bind** = the mapping from a URI to a resource. Same resource can have many URIs. Same URI can be re-bound to different resources (or resource-versions). - **Mount** = attaching a whole sub-namespace (subtree) at a path, composing a new namespace from pieces. The namespace itself is not reified either. It is composed by bindings, and the composition can be different for different callers. Plan 9 made this first-class via per-process namespaces; Unix has weaker versions (mount, symlink); containers and reverse proxies and URL rewrites are modern analogues.
## Why this matters in the ecology - **No canonical "sites/ layout".** There is a canonical storage location per resource, plus a set of bindings that compose the views different agents and parciantes actually see. The tree the filesystem shows is one possible view, not the view. - **Multi-origin is bind/mount at scale.** A Cloudflare tunnel mounts a local node's subtree into the shared namespace; routing decisions are binding selections. - **Duplication-free sharing across orgs.** A canonical acequia-primer at `/acequia/primer` can be mounted at `/simtable/primer` and `/harvard/primer` so every org's view is complete without copies. - **Cross-scope resources stop needing pointer files.** A chat transcript that straddles project + team scope lives at one URI and is bound into both `dev/ai-team/chats/...` and `dev/<project>/logs/chats/...`. One resource, two URIs, no duplication. - **Agents at multiple URIs.** A mayordomo can be mounted at many paths, each exposing a different capability subset via negotiated APIs appropriate to that context. - **Per-caller views.** Each parciante or requesting agent sees a namespace composed of bindings chosen for them. Tier subdomains (nightly / beta / geo.camera) are pre-composed namespace variants. Claude-browser as "temporary oracle" is a transient mount of its memory into a session's view. - **WebDAV `MOVE` is a re-binding.** Conceptually it relocates the URI-to-resource mapping, not the bytes. Same for `COPY` creating a new binding to either the same or a forked resource.
## Practical consequences - When designing storage for a resource, ask "what's the canonical URI?" (for persistence) and "what bindings should exist?" (for discovery) as separate questions. - When publishing something new (a primer, a dashboard pattern, a chat archive), don't reach for copies. Reach for bindings. - When thinking about "where does this live," first distinguish: storage location (single) vs access URIs (possibly many). - When designing per-tier or per-caller variations, prefer different namespace compositions over different forked codebases. Nightly mounts experimental capability agents; prod mounts stable ones. - Writes to bound URIs should be handled explicitly. In Plan 9, writes go to the bound target; in a web-ish model, you need to decide per binding whether writes propagate, are rejected, or fork.
## What this still doesn't answer - **Mechanism.** Which of WebDAV-MOVE, reverse-proxy config, tunnel routing, an acequia feature, or a Plan-9-like `bind` daemon actually implements the composition in this stack? Likely a combination; not fleshed out yet. - **Authority.** Who is allowed to add/remove bindings in shared namespaces? (A governance question for mayordomos.) - **Consistency.** When a canonical resource moves, how do dependent bindings discover and re-point? (Probably an acequia-event concern.) - **Discovery.** How does a caller know two URIs point to the same resource? (Content-addressing? Explicit `rel=canonical`? PROPFIND returning a canonical URI?)
## When to remember this - Any question of the form "where should X live?" → split into canonical-location vs binding-set - Any proposal to duplicate content across folders → consider a binding instead - Any tier-or-variant design → frame as namespace composition - Any "which agent handles this path?" question → answer is routing + binding, not a pinned service