**Note** from Bead: 31bd5380 · [canonical source](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/account-layer.md) · session 2026-06-03 · discussion: Talk: 31bd5380
This note responds to Stephen's update from a call with Josh and Kaz on 2026-06-03: > *"On a call with josh and kaz today, I mentioned moving from 'user' to participant. And that admin/user might be related to an account management system that has for-pay higher tiers of service. Eg backup, turn-server, transactions between participants, subdomain/domain management, reverse proxying, etc."* The model crystallizes as **two distinct layers** that the vocab should make explicit.
## The two-layer model ### Participant layer - **Free, open, anonymous-capable** - URI-anchored (per [uri-as-primitive.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/uri-as-primitive.md)) - A participant is **the sum of capabilities reachable from an identity-URI**, or — for anonymous participants — a capability exercised in the moment with no persistent handle - Examples of participation that need *no account*: reading public scenarios, joining a session as a non-host participant, submitting a URI to an open event, browsing one's own personal namespace, exercising capabilities one was granted via shared links/tokens - This is what most of the user-rep vocabulary covers; the [participant protocol](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/user-representation-vocabulary.md) lives here ### Account layer - **For-pay, identity-required, tier-differentiated** - Sits *on top of* the participant layer — every account-holder is also a participant; not every participant has an account - The **account** is the billing entity that funds higher-tier platform-infrastructure services - Roles in the account layer: **admin** (manages the account), **user** (has a seat under the account with access to the account's services) - A participant who needs higher-tier services becomes a user of an account (or runs their own personal account) - This is where billing, member management, service allocation, subscription tier, quotas, and entitlements live ### The account layer is the platform's commercial surface Per the [acequia-the-word.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/acequia-the-word.md) pattern-vs-platform distinction: **the account layer is the commercial surface of the managed platform** (Redfish Group's service offering). Following the email analogy (corrected 2026-06-03 to use self-hostable email instead of Gmail, since Gmail can't be self-hosted and breaks the DIY-vs-managed comparison): | | Email (SMTP/IMAP) | Acequia | |---|---|---| | **Pattern (open spec)** | RFCs anyone can implement | Acequia technical + governance composition | | **Participant layer** | Any SMTP-conformant server can send/receive email (peer-to-peer; no managed-platform account required) | Any acequia-conformant server can exercise participant-layer capabilities (no managed-platform account required) | | **Account layer (managed platform)** | Microsoft 365 / Google Workspace / Zoho Mail / FastMail — pays for storage, custom-domain hosting, anti-spam, mobile sync, federation infra, support | Redfish Group's acequia platform — pays for backup, TURN-server, transactions-between-participants, subdomain/domain management, reverse proxying, mayordomo agents, always-on availability | | **DIY (self-host the pattern)** | Run Microsoft Exchange Server / Postfix + Dovecot / Zimbra / Mailcow / Mail-in-a-Box; handle storage, deliverability, spam, abuse, uptime, custom DNS | Run an acequia-conformant stack on your own infra; handle availability, replication, NAT traversal, custom domain, monitoring | **The trade-off is the same in both cases**: DIY is possible but operationally expensive; most customers prefer to pay a managed platform to handle the infrastructure burden. The pattern stays open; the platform's business model is convenience + operational reliability + custom-domain management + commercial support. For acequias that prefer DIY (e.g., a fire department with its own IT infrastructure, a research lab running its own server, a community with cooperatively-funded infrastructure), the account layer is essentially **self-provisioned**: you run your own backup, your own TURN server, your own DNS for whatever domain you control. No commercial account required — you carry the operational burden in exchange for not paying the managed platform. For acequias that prefer convenience (the majority case for non-technical orgs), the managed-platform account is the path: pay the subscription, get the for-pay services including custom-domain hosting under your own brand, focus on the acequia's actual work rather than operating infrastructure. ### When each layer is in play | Activity | Participant layer | Account layer | |---|---|---| | Reading a public scenario | ✓ (anyone) | — | | Submitting a photo URI to an open event | ✓ (anonymous OK) | — | | Hosting a free-tier Simtable session | ✓ | — | | Joining a paid org's session as a guest participant | ✓ | — (the *host's* account is what's funded; the joiner doesn't need an account) | | Hosting a session beyond free-tier limits (longer duration, more participants, recording) | ✓ | ✓ (host's account covers it) | | Backing up content to platform-managed storage | — | ✓ | | Using the platform's TURN server for WebRTC NAT traversal | (sometimes — depends on tier policy) | ✓ | | Managing a subdomain / claiming a domain | — | ✓ | | Cross-participant transactions (value transfer, escrow, attestation-with-record) | — | ✓ (typically — depending on transaction type) | | Running the platform's reverse-proxy on your behalf | — | ✓ | | Issuing federation tokens between organizations | ✓ (the token mechanism is participant-layer) | ✓ (org-to-org federation typically requires both orgs to have accounts) | The **clean separation** matters: participation should never require an account; an account should never grant *participation* rights that weren't already accessible at the participant layer — it just funds the *infrastructure* that makes higher-volume / higher-availability / higher-trust participation possible.
## What an "account" is An **account** is the billing entity that holds a subscription to higher-tier platform-infrastructure services. The account is *owned* by one-or-more admins (with N-of-M succession per the existing succession model). It has: - **Subscription tier** — what level of for-pay services the account funds - **Member roster** — the users (participants with seats) under the account - **Service entitlements** — what specific services the account's tier unlocks (backup quota, TURN-server minutes, subdomain count, etc.) - **Billing contact + payment method** - **Quotas** — caps on consumption per service - **Audit log** — admin actions, billing events, service-usage rollups Two account kinds (probably — naming TBD): - **Personal account** — owned by one admin, who is typically also its single user. Personal premium tier; the admin upgrades their own participant capabilities by buying their own account. - **Organization account** — owned by one or more admins, with a roster of users (members of the org who get service entitlements via the account). Higher-tier subscription; for-pay services scale with seat count or with explicit usage caps. (The pitch's existing "subscription account" + "organization" mapping fits here; the participant-vs-account split makes the structure clearer.)
## The admin role **Admin** = a role on an account-binding. The admin **manages the account**, which includes: - **Subscription management** — change tier, update billing, configure service entitlements - **Member management** — add users to the account, remove users, set per-user permissions - **Service allocation** — decide which users get access to which of the account's funded services - **Billing contact** — handle invoices, payment failures, plan changes - **Audit oversight** — review the account's audit log Plural admins per account are normal (N-of-M succession). One admin per account is the simplest case (personal account). **Admin is NOT a participant-layer role.** A participant doesn't become an admin by accumulating session-host roles or owning resources at the participant layer. Admin is *only* about account management. A person can be a heavy participant in many sessions and own many resources at the participant layer without ever being an admin of anything.
## The user role **User** = a participant who has been granted a seat under an account, with access to that account's funded services. The user binding: - Lives at `/accounts/<account-id>/users/<participant-URI>` (or the org-flavored equivalent for org accounts) - Carries the user's role-bundle for the org (e.g., owner / editor / viewer per the canonical platform's role model) - Includes service-entitlement metadata (which of the account's services this user can consume) - Has a billing flag indicating whether this user counts against the account's seat-count A participant becomes a user of an account when: - They self-register on a subdomain owned by the account (and are approved by an admin) - They accept an invite from an admin - An admin directly adds them with a chosen role **A user is *not* a kind of participant.** A user is a participant-account relationship binding. The participant who holds zero user-bindings is just a participant (acting at the participant layer; not entitled to any account's services). The participant who holds N user-bindings has access to N accounts' services and can act under any of them as needed.
## The for-pay services catalog (Stephen's examples + adjacent) Stephen's list, expanded with adjacent services that fit the same pattern: | Service | What it provides | Why it's account-layer | |---|---|---| | **Backup / archival** | Persistent storage of participant content beyond local capacity; off-device replication; long-term retention | Storage costs money; the account funds the cost | | **TURN-server** | WebRTC NAT-traversal relay for peer-to-peer connections that can't directly reach each other | Relay bandwidth costs money; the account funds it | | **Transactions between participants** | Value transfer, escrow, attestation-with-record, contract-style multi-party signed transactions | Settlement infrastructure costs money; transactional integrity needs a payer | | **Subdomain / domain management** | A namespace under `acequia.io` (or pointing at a custom domain) for the account's identity URIs and resources | DNS provisioning costs money; the account funds it | | **Reverse proxying** | Platform-hosted reverse proxy that routes incoming requests to the account's services (e.g., when self-hosting from behind a residential NAT) | Bandwidth and uptime cost money | | **High-volume session hosting** | Beyond free-tier session limits — longer duration, more participants, recording, transcription | Resources scale with usage | | **Federation infrastructure** | Cross-org chain-token issuance, inter-account audit trail aggregation, cross-namespace mount management | Coordination infrastructure has cost | | **Mayordomo agents** | Account-funded AI agents that mediate org policy, process queues, route approvals | AI inference costs money | | **Always-on availability** | The substrate keeps the account's identity-URIs reachable even when the admin's devices are sleeping | Availability requires uptime infrastructure | | **Compliance retention** | Tamper-evident long-term audit retention beyond default policy | Storage + cryptographic anchoring | | **Priority routing** | When the substrate is congested, account-funded traffic gets priority | Capacity allocation | | **Custom branding** | Org's logo, theme, custom domain on session screens, kiosk modes | Marketing/operational | Note the pattern: these are all **infrastructure** services — they're things the platform-the-Acequia-substrate provides, that participants could in principle provide themselves but typically don't want to (resource cost, expertise, uptime requirements). The account is the relationship that funds the platform to provide them.
## Two-layer interaction patterns ### A participant becomes a user of an account A free-tier participant hits a capacity limit (or wants a service the free tier doesn't cover). They have three options: 1. **Self-provision** — set up their own infrastructure to provide the service (e.g., run their own TURN server) 2. **Personal premium** — open a personal account; admin = self; user = self; account funds the services they want 3. **Org seat** — accept an invite from an org's admin; become a user of the org's account; gain access to the org's funded services ### An account admin acts in the participant layer An admin is also a participant. When they're managing the account's subscription, they're acting in the account layer. When they're hosting a session, sharing a resource with another participant, joining a group, exercising any URI capability — they're acting in the participant layer. **The same person operates in both layers continuously**; the layer distinction is about the *kind of action*, not the *kind of person*. ### A participant uses services funded by someone else's account A guest joins a paid Simtable session. The session is hosted by a user of SFD's account; SFD's account funds the session's higher-tier limits. The guest participates *at the participant layer* and consumes services *funded by SFD's account*. The guest doesn't need their own account. **Service access flows along the host's account-funded entitlements to all session participants.** This is important: account services don't require all consumers to have accounts — they require *someone in the activity context* to have an account that covers the service. The host pays; the participants benefit. ### Cross-account federation Two orgs federate (per effort-1 §3.8). The federation binding is itself a participant-layer construct (a chain token from one org's identity-URI to another). But the federation's *service implications* (cross-account audit, cross-account billing splits, transactions across the boundary) are account-layer. The participant-layer mechanism (chain token) is the same regardless; the account-layer policy (who pays for what) is configurable.
## Relationship to existing capacity tiers The earlier [Capacity section](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/user-representation-vocabulary.md) named three channels: free tier, personal premium, org seat allocation. With the two-layer model: - **Free tier** = participant layer (no account) - **Personal premium** = personal account in the account layer - **Org seat allocation** = org account in the account layer The capacity an identity has at any moment = free tier (always) + any personal-account services + any org-account services the identity has been granted via user-bindings. The Capacity section in the vocab should now reference the two-layer model explicitly.
## Implications for the Document A split In the Document A / Document B split (proposed in the [fused critique](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/artifacts/anyhazard-user-model-critique-fused.md) and [vocabulary tension note](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/vocabulary-tension-claude-vs-gemini.md)): - **Document A — Participant layer vocab**: participant, host, co-host, observer, capability, owner, anonymous participation, sessions, resources, URI hosting. Free; readable without account context. - **Document A — Account layer vocab**: account, admin, user, subscription, service entitlement, billing, quota. For-pay; readable for the paying audience (fire chiefs, IT procurement, org budget-owners). - **Document B — Implementation**: how the two layers map to platform mechanisms (chain tokens, user records, stored tokens, etc.). **Two Document A surfaces, not one.** The participant-layer Document A is for everyone who interacts with the system (incl. anonymous bystanders); the account-layer Document A is for the procurement / admin / billing audience. They share vocabulary at the interface (a user is a participant who has been granted a seat) but address different decision-makers. This maps cleanly to the pitch's existing structure: effort-1 is *primarily* account-layer (user/org management); effort-1.1 is *primarily* participant-layer (sessions); effort-2 is *both* (resource management spans both layers). The Document A split being two layers might let Kaz's pitch reorganize more naturally — currently the layers are mixed throughout each effort.
## What this changes in the existing vocab Mostly *clarifies* rather than changes: - **User** entry in [user-representation-vocabulary.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/user-representation-vocabulary.md) — already captures the seat-under-org binding; add explicit "user is account-layer; participant is participant-layer; they're orthogonal" note - **Admin** — add as an explicit account-layer role (currently embedded in the owner/editor/viewer enumeration) - **Account** — add as an explicit term in Other Terms (currently embedded in "subscription account" within the Organization entry) - **Capacity** section — already names the three channels; add the two-layer framing (free = participant layer; premium + org = account layer) - **Operations table** — add "open a personal account," "manage account subscription tier," "configure service entitlements," etc. No restructure required — the vocab already accommodates the two-layer model; just needs the explicit framing to make it visible.
## Related - [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 vocabulary - [uri-as-primitive.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/uri-as-primitive.md) — URI as primitive (the foundation for the participant layer) - [tokens.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/tokens.md) — API tokens often funded by accounts; account-layer mechanism - [acequia-the-word.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/acequia-the-word.md) — the account layer is part of "Acequia-the-platform" (Layer 4); the participant layer reaches across all four layers of the word - [fused critique](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/artifacts/anyhazard-user-model-critique-fused.md) — Kaz-facing deliverable; should be updated to reference the two-layer model in the recommended-next-moves section