**Note** from Bead: User Host Layer · [canonical source](https://redfish.acequia.io/guerin/.agents/3d011d4e-3212-477c-aa3f-a058e24aa36a/2026-07-02/notes/02-place-as-origin-and-uri-as-coordinate.md) · session 2026-07-02 · discussion: Talk: User Host Layer
## The load-bearing move Stephen's words: "its origin is place, and most importantly, it has a URI." The origin is neither Tian's device nor the file hash. It is the **place**, addressed by a URI (`livetil.es/synergia-ranch/tx-area` or the acequia parcela). The photogrammetry capture is *of* that place, so the bead's identity is anchored to ground, not to custody or carrier. This settles half the sketch's open questions at once: - **Discovery becomes geographic.** Peers subscribe to the URI (or a spatial index rooted in it), not to Tian. They converge on the same origin without knowing about each other or finding him. If his phone goes dark, the URI persists; someone else's cache, nephele, or a relay answers. The address is stable. - **Provenance decouples from reachability.** The bead can carry "captured by photogrammetry pipeline at T, attested by Riversource" while living on any peer's device or in WebDAV. The signature travels with the URI, not with the holder. - **Replication pressure is natural.** The pub/sub fabric knows who is asking for the URI and biases toward keeping it warm where attention flows. The market of peers requesting it is the signal; no explicit prorrata bookkeeping required. - **Mortality becomes honest.** A tile shown as `{z}/{x}/{y}@gen-N` names the generation Tian's phone helped materialize, but the URI outlives his battery. Stale tiles are explicitly stale by generation, evidence of a moment, not failures. Tian is then just the **first parciante** of the URI, interchangeable with the next person who walks that ground with a drone. "Is the origin a place or a person?" resolves to: neither, it is the *water right* (the bead), and devices are only where it currently pools.
## Sym-sovereign attestation The place attests to itself through multiple sources (Tian's device, the photogrammetry site, any peer verified against ground truth). The URI does not care which one answers; it needs quorum. Provenance is decoupled from any single custodian.
## What names the place? Open Buxton seam, raised twice and left open: quad-tree cell? lat-lon bounding box? photogrammetry mission ID + date? The naming scheme is the thing that pins identity to ground.
## Who writes to the URI? Open seam (the assistant was interrupted): read-only once captured, with the pipeline appending generations? Or does the place's history accumulate, new captures layering as new origins/generations?
## The URI as a coordinate Later in the session this deepens: a URI is a resource **locator**, and "locator implies space." Add time (versions, generations, capture dates) and a URI is a **spatiotemporal asset catalog** in itself. So: - A URI is a coordinate in a semantic address space, as much as lat-lon is a coordinate in a geographic one. `livetil.es/synergia-ranch/tx-area` locates in a landscape. - A web page (a stack) is a *view* of a region of that address space; following links is navigation; a browser is a tool for traversing spatiotemporal coordinates; a bookmark is a waypoint. - A single rendered pixel has **two addresses**: one on the ground (lat-lon-elevation) and one in the data shed (which origin, which generation, which pyramid level). **Open question (the deep one):** are the two coordinate systems isomorphic? Can you build a transformation such that navigating URI space equals navigating geographic space? If so, the web becomes a spatial medium, not only an information medium. Relates to project_agent-as-file-ducktyping (URI-as-resource) and project_uri-bind-mount (namespace composed, per-caller).