**Note** from Bead: 31bd5380 · [canonical source](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/uri-as-primitive.md) · session 2026-06-03 · discussion: Talk: 31bd5380
This note foregrounds the structural commitment Stephen named in chat (turn 32, 2026-06-03): > *"I really want to foreground URI as primitive. It may be that a user is the sum of capabilities of URIs. Eg if I have my own URI I can share it at an event or scenario that lets people submit URIs even anonymously."* The shift this asks for is deeper than what [user-representation-vocabulary.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/user-representation-vocabulary.md) currently expresses. That note has identities (person, org, AI agent) as primary and bindings/capabilities as derivative. **Stephen's frame inverts the order: capabilities at URIs are primary; identities are derivative bundles.** The platform's chain-token discipline already operates this way at the cryptographic level — chain tokens *are* capabilities; possession is permission; identity is derived from "who currently holds which tokens" ([chain-tokens-and-oauth.md](https://redfish.acequia.io/guerin/.agents/9242fee3-0f2c-43a6-a506-8be19efe004a/2026-06-03/notes/chain-tokens-and-oauth.md) covers this in depth, including the UCAN family resemblance). Stephen's directive is to **make the user-facing vocabulary match what the substrate already does**. Stop hiding the capability discipline under "identity" as the primary noun.
## The inversion | Identity-centric (current vocab default) | URI-centric (this note) | |---|---| | Person, organization, AI agent are **first-class entities** | Person, organization, AI agent are **named bundles** of URI capabilities | | Capabilities are **properties of identities** | Capabilities are **anchored at URIs** | | A user is a kind of entity (or a relationship) | A user is **the sum of capabilities reachable from an identity-URI** plus capabilities held independently | | Anonymous participation is a **special case** ("guest mode," "ephemeral access") | Anonymous participation is the **default** — you exercise a capability; whether you ALSO have a registered identity is orthogonal | | Identity comes first; what you can do follows from who you are | What you can do comes first; **"who you are" is shorthand** for the bundle of capabilities currently in your possession | | Sharing requires identifying the recipient | Sharing is exposing a capability at a URI; anyone with the URI can exercise it | This isn't a vocabulary cosmetic. It's a structural commitment with downstream consequences across the whole pitch surface.
## The event-submission worked example Stephen's example unpacked concretely: > *"If I have my own URI I can share it at an event or scenario that lets people submit URIs even anonymously."* ### Setup Stephen (or SFD) sets up an event at a URI: ``` https://anyhazard.acequia.io/events/sfd-2026-spring-drill/ ``` This URI has sub-resources, each with its own capability surface: ``` /events/sfd-2026-spring-drill/ ├── about # event description (public read) ├── policy/ │ ├── submission-mode # "open" / "captcha-required" / │ │ # "attestation-required" / "members-only" │ └── retention # how long submissions persist ├── submissions/ # POST endpoint (per submission-mode policy) │ ├── 2026-06-03T1015Z-<id1> # a submitted URI + metadata │ ├── 2026-06-03T1023Z-<id2> │ └── ... ├── curated/ # subset promoted by event hosts ├── stream # SSE subscription for live submissions └── audit # who submitted what when (immutable) ``` ### Sharing the URI at the event "Sharing" the URI means **making it reachable** in the physical/social context of the event: - The URI is rendered as a QR code on screens at the event venue - It's printed on handouts, on the projector, on the Simtable display - Anyone with a phone camera can scan and reach the submissions endpoint The act of sharing is *just exposure of the URI*. No invitation flow, no recipient list, no identity required to be shared-with. ### The anonymous submission flow A bystander at the drill captures a phone photo. Walk through their actions: 1. They take a photo on their phone (the photo lives at some URI: maybe `https://phone-cache.local/photo-123.jpg`; maybe uploaded to a free public-pinning service; maybe a transient URI valid for the next 10 minutes) 2. They scan the QR code at the event location → their phone opens `https://anyhazard.acequia.io/events/sfd-2026-spring-drill/` 3. The event page exposes a "Submit a URI" affordance (or accepts a paste-URL form) 4. They paste their photo's URI and tap submit → browser `POST`s to `/events/sfd-2026-spring-drill/submissions/` 5. The substrate accepts per the event's `submission-mode` policy (in "open" mode, no authentication required; in "captcha-required" mode, a captcha challenge intervenes) 6. The submission is recorded with whatever attribution is **available** (timestamp, IP if not anonymized, optional self-provided contact email, optional captcha-derived proof-of-humanity) 7. The submitter walks away. **No identity has been created.** No "guest user account." No anonymous identity URI. Just a capability exercised against a URI. ### What changed vs identity-centric framing Under the identity-centric model, anonymous submission requires: - A "guest mode" feature (effort 1.1's Guest mode applies to session-hosting; would need extension to submission) - A "Pending" user identity that gets created and then aged out - A separate auth path that doesn't require keypair registration - Special-case handling throughout (audit, billing, quota, retention, policy) Under URI-as-primitive: **none of that exists**. The submission endpoint has a policy; the submitter exercises a capability; the URI namespace grew by an edge. The "no identity" case isn't a special-case feature — it's just the case when the submitter chose not to attach an identity. If the submitter *wants* more (acknowledgment in curated/, notifications about how their submission was used, attribution in any derivative work), they can voluntarily attach identity material at submission time — a contact email, a registered handle, a chain-token signature. But the *default* is identity-free, and that's a normal case, not an exception.
## Identity as derivative — what a "user" actually IS Under URI-as-primitive, identity is shorthand for **the bundle of capabilities reachable from a named URI**. When we say "Jane the fire chief": - We mean: the capabilities reachable from `/people/jane-smith/` plus all the capabilities Jane currently holds in her devices' token stores - The "person Jane" is the convergence of these capabilities at the identity-URI; it's a name for the bundle, **not a thing with its own ontological status** - If Jane loses all her devices (and all her tokens), she's still the same person *to other humans* but she's *no capabilities in the system* — the identity URI exists but accumulates no capability. The convergence is empty. - If a brand-new person registers under the URI `/people/jane-smith/` after the original Jane departs (her identity-URI is apoptotically-completed and recycled), the URI is the same but the convergence is different. **The URI is the address; the capabilities are the substance.** This is the **capability-discipline view of identity** ([ocap](https://en.wikipedia.org/wiki/Object-capability_model), UCAN, Macaroons, the whole family the chain-tokens-and-oauth note traces): an identity is what you can do, not what you are. Names are for human convenience; the cryptographic reality is "which capabilities are currently held." ### Per identity-type For a **person**: - Persistent identity URI (e.g., `/people/jane-smith/`) — the address at which capabilities accumulate - Held capabilities — what's actually in Jane's tokens, device keys, registered chains, accepted invites - The "user Jane" = the latter, addressed by the former For an **organization**: - Persistent identity URI (e.g., `/orgs/sfd/`) — the address - Held capabilities — what's bound under the SFD URI subtree, plus federation-bindings, plus API tokens issued under SFD's name - The "organization SFD" = the union, addressed by the URI For an **AI agent** (when given an identity URI at all — often not needed): - Same pattern; the agent's "identity" is the union of capabilities reachable from its agent-URI For an **anonymous contributor**: - No persistent identity URI - Holds one capability in the moment (the submission token, the QR-code-derived capability, the public-write authorization on the event URI) - The "anonymous participant" = that one capability; nothing accumulates because there's no address For an **AI agent represented as a named API token** (the platform's current pattern): - No agent identity URI per se - The API token IS the capability bundle (the name describes what it can do) - The holder exercises the token; the issuing user's identity backs the chain - "The wiki.acequia.org-mayordomo" = the bundle of capabilities the token grants, addressed by the token's name
## Anonymous participation as a first-class vocabulary term **Anonymous participation** — exercising a capability at a URI without holding (or revealing) a persistent identity-URI. The participant exists in the moment of exercising the capability; the system has no persistent handle for them. Examples in AnyHazard / Acequia contexts: - A bystander at an incident submits a phone photo to an event URI - A community member upvotes a public scenario at its URI - A passerby uses a public Simtable kiosk in idle/Guest mode - A federation partner POSTs to a cross-org `incoming/` URI without identifying themselves (the federation token *itself* is the identity assertion — the holder is anonymous) - A field witness submits a sensor reading to a sealed-incident URI - A community-meeting attendee scans a QR and writes a comment that lands at a meeting URI Anonymous participation is **NOT "guest mode"** — guest mode is a feature toggle that creates a temporary identity. Anonymous participation requires *no identity at all*. The capability is in the URI's submission-mode policy; the exerciser holds nothing persistent. ### Anonymous-participation operations table | Intent | URI verb + path | Identity required? | |---|---|---| | Submit a photo URI to an open event | `POST /events/<E>/submissions/` body: URI + optional metadata | No | | Read a public scenario | `GET /orgs/<O>/scenarios/<S>` | No (if scenario is public-readable) | | Subscribe to a public sensor stream | `GET /sensors/<S>/stream` (SSE) | No (if sensor is public) | | Submit a witness statement to a sealed incident URI | `POST /incidents/<I>/witnesses/` body: text + optional contact | No (but submission-mode may require captcha or attestation) | | Host a public kiosk session at a Simtable | `PUT /sessions/<S>/host` with no identity | Per Guest-mode policy — may allow or require minimal attestation | | Read the live camera feed at a public vantage URI | `GET /cameras/<C>/stream` | No (if camera is public-readable) | | Acknowledge a community alert (e.g., "I see it too") | `POST /alerts/<A>/acks/` with optional location | No | ### What enables anonymous participation safely - **Policy lives at the URI** — the `policy/submission-mode` sub-URI declares what's allowed (open, captcha-required, attestation-required, members-only). The policy is the gate. - **Attribution is best-effort, not required** — timestamp, IP (or anonymized region), optional self-provided contact, optional captcha proof - **Retention is bounded** — anonymous submissions have a retention policy; they can age out - **Curation is separate** — host/co-host can promote submissions to `curated/`; the act of curation attaches some identity to the submission *at the curator's end*, not the submitter's - **Rate limiting and Sybil resistance** happen at the URI's policy layer (per-IP throttling, captchas, proof-of-personhood challenges) — not by requiring identity
## What this changes for the broader vocabulary Once URI is the primitive, several other vocabulary entries simplify or shift their framing: - **Person, organization, AI agent** — stay in the vocabulary but as *names for capability bundles addressed at identity-URIs*, not as primary primitives. Useful shorthand; not foundational. - **User-of-org binding** — still useful; now framed as "a person's identity-URI accumulates the capability of being a billed seat under the org's URI." - **Participant-of-session binding** — still useful; now framed as "a person/agent's identity-URI accumulates the capability of being in this session," OR (for anonymous participants) "this capability has been exercised at the session URI." - **Host (role)** — still a role; now framed as "the capability of session management is bound to this participant for the session's duration." The host *holds* the capability; if it's transferred, the holder changes. - **Owner** — same shift; the resource's owner is "the identity-URI whose accumulated capabilities include full control of this resource." - **Tokens** — already capabilities (the platform's chain tokens ARE capabilities). The vocabulary becomes consistent: **tokens are how capabilities are made portable.** A token is "this capability, in transferable form." - **API tokens (named, for non-human identities)** — even more naturally framed: a named API token IS a capability bundle; the name describes what it can do; the holder exercises it; no underlying separate identity-type is required beyond the issuing user's identity-URI. - **URI hosting / pinning / CDN participation** — already URI-centric; now consistent with the rest of the vocabulary.
## The chain back to the foundational vision This frame doesn't conflict with anything in the [bead 874fce5b vision notes](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/). It **tightens alignment**: - **[Polarized links](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/polarized-links.md)** — every link is a capability assertion at the link's destination URI; identity is who's-asserting-the-link, but the **link is the primitive** - **[URI bind/mount](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/uri-bind-mount.md)** — the URI is composed; identities are participants in the composition - **[Agent-as-bead](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/agent-as-bead.md)** — agents are URIs that hold capabilities; the bead IS the URI, not a wrapper around it - **[Paths-as-event-bus](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/paths-as-event-bus.md)** — events happen AT URIs; participants exercise capabilities at the event URI (the submission example is literally this pattern) - **[Advanced-wave](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/advanced-wave.md)** — attribution flows through URI references; the ledger is URI-anchored - **[Self-assembling-wires ecology](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/self-assembling-wires/ecology.md)** — capabilities self-organize around demand at URIs (the parciante-as-bearing-in-an-acequia metaphor is precisely this) The vision frame has been URI-primary all along. The user-vocabulary note's identity-primary structure was a concession to **SaaS-conventional readability**. Stephen's directive: stop conceding. Foreground the URI.
## What this means for Kaz's pitch The pitch's structure assumes identity-primary throughout. Inverting to URI-primary is a Document-A-level commitment that: - **Lets the pitch accommodate anonymous participation** without inventing "guest mode" as a special case for every flow (submissions, kiosk usage, community input) - **Lets events and scenarios accept submissions** without requiring a user account flow — opens the platform to bystanders, witnesses, community contributors, anyone with a URI in their hand - **Simplifies cross-org collaboration** — federation becomes just "URI capabilities flowing between namespaces" - **Clarifies the relationship between user accounts and what users actually DO** — the account is the address; the doing is the capabilities - **Maps directly to the platform's chain-token discipline** — the user-vocab and the platform-vocab stop diverging This is closer to **how the cryptographic substrate already works** (chain tokens, capability discipline, [chain-tokens-and-oauth.md](https://redfish.acequia.io/guerin/.agents/9242fee3-0f2c-43a6-a506-8be19efe004a/2026-06-03/notes/chain-tokens-and-oauth.md)) than to how the pitch's user-facing vocabulary currently presents. It is a substantial reframe. Not a small one. The trade-off: - **Cost**: readers familiar with SaaS-conventional user-as-primary thinking have more to absorb; the spec asks more upfront - **Benefit**: the spec ends up consistent with the underlying substrate, accommodates a wider range of participation modes, and doesn't accumulate "special case" features over time as the platform meets new use cases The bet is that the upfront cost is paid once and the benefit compounds.
## What this note doesn't decide - **Whether identity-URIs are *recommended* for typical use** — yes; they're convenient for accumulating capabilities. The frame just clarifies that they're not *required*. - **Whether existing pitch features must be rewritten** — no, not wholesale; most of them are still valid, just better-framed under URI-primary - **Whether the platform itself needs changes** — minimal; the platform already operates capability-first at the cryptographic layer. The change is at the vocabulary / Document-A level, not at the implementation level - **How to phase the change** — Document A can be rewritten incrementally; existing pitch features can be re-anchored one at a time without breaking the platform
## Related - Companion vocabulary: [user-representation-vocabulary.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/user-representation-vocabulary.md) (the broader Document-A entries, now anchored to this frame) - Worked URI expression: [participants-and-resources-in-uri-sense.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/participants-and-resources-in-uri-sense.md) (concrete URI patterns) - Token mechanics: [tokens.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/tokens.md) (how capabilities become portable) - Chain-token / capability theory: [chain-tokens-and-oauth.md](https://redfish.acequia.io/guerin/.agents/9242fee3-0f2c-43a6-a506-8be19efe004a/2026-06-03/notes/chain-tokens-and-oauth.md) - Foundational vision frame: [bead 874fce5b](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/)
## References (bead cross-links) - Bead: 9242fee3 · [canonical](https://redfish.acequia.io/guerin/.agents/9242fee3-0f2c-43a6-a506-8be19efe004a/) - Bead: 874fce5b · [canonical](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/)