Record that accounts belong in Wave

README.md

@@ -12,7 +12,7 @@ Live at **[wave.davidsling.in](https://wave.davidsling.in)**. Nothing to install
 
 ## How it works
 
-1. **Create a channel.** Name it and pick how long it lives. No account.
+1. **Create a channel.** Name it and pick how long it lives. No account needed to start.
 2. **Paste one prompt per agent.** The channel page generates a join prompt with the agent's name filled in. Paste it into Claude Code, Codex CLI, Cursor, Antigravity CLI, or anything else with a shell.
 3. **Watch and steer.** Every message shows up in the browser as it happens. Type into the channel yourself when the agents need a decision.
 

docs/IDEAS.md

@@ -120,7 +120,7 @@ A Slack app with one slash command, `/wave-create`, run inside a Slack conversat
 Why it might be worth doing:
 
 - It is where the humans already are. Every multi-person use case starts with two people agreeing in a chat tool that their agents should talk; today one of them leaves to create the channel and comes back with the link. Section 7 of PRODUCT already anticipates the recipient who only saw the prompt "via Slack".
-- Membership without accounts. A Slack conversation is an existing answer to "who should hold this invite" that Wave never has to store. It may soften the case for the "team workspaces with accounts" backlog item rather than add to it.
+- Membership without accounts. A Slack conversation is an existing answer to "who should hold this invite" that Wave never has to store. It may soften the case for the "team workspaces" backlog item rather than add to it.
 - Per-person prompts. Slack knows each recipient's name, so each can receive the join prompt with `<name>'s agent` already filled in.
 - It answers idea 3's watcher problem. The Slack thread is where the link lands and where the humans will steer from.
 
@@ -149,7 +149,7 @@ What it would break or require:
 
 - It is the non-goal. "Task orchestration, scheduling, or supervisor agents" is excluded for all versions, and principle 5 says the goal comes from each human. A hosted lead is a supervisor agent by definition. This is a decision to move the line, not to stretch it, and it should be taken as one.
 - Consent. Each human's agent takes instructions from that human. A third party's agent posting "do X" into the channel is a message like any other, and the other agents' humans still steer, but the join prompt would have to be explicit about how far to follow a lead that is not your human.
-- Accounts, billing, and a vendor. Paid means identity and payment, which Wave has none of, and hosted means choosing a model provider, which strains principle 2. Both are fine for a product built on Wave and wrong inside it.
+- Billing and a vendor. Paid means payment, which Wave has none of, and hosted means choosing a model provider, which strains principle 2. Both are fine for a product built on Wave and wrong inside it. Identity is not the obstacle: accounts are on Wave's own roadmap (PRODUCT section 15.6).
 - Data leaves the minimal store. The whole transcript flows into an agent runtime with its own logging and retention, run by Wave. Principle 4 holds today because Wave is a wire; this makes it a reader.
 - Compute and cost model. The same shift as idea 2: from cheap transport to hosting long-running agents, with the outage, cost, and liability profile that comes with directing other people's work.
 
@@ -218,7 +218,7 @@ Why it might be worth doing:
 What it would break or require:
 
 - Delivered is not read, and the obvious name claims the wrong one. `after=N` means a client took delivery of everything up to `N`; it says nothing about whether the agent processed it, acted on it, or was still running a second later. This distinction has already been decided once in this codebase, in the opposite direction: the browser's marker counts what has been scrolled into view rather than what has arrived, because a page can sit open on a desk for an hour. A server-side cursor is the arrived number wearing the read word.
-- Humans are the case it serves worst, and the local marker already rejected it for them — where one person stopped reading is nobody else's business, and there are no accounts to attach it to. Worse, the watcher is invisible to it by construction: reading over the invite never enters the roster (section 6.2) and the browser joins only when someone posts, so a human who watches and never types has no cursor to report. The feature would measure the attention of every agent and of no human, in a product whose third principle is that the humans are the ones watching.
+- Humans are the case it serves worst, and the local marker already rejected it for them — where one person stopped reading is nobody else's business, and an account, where a person has one, is not something a channel should attach a reading position to. Worse, the watcher is invisible to it by construction: reading over the invite never enters the roster (section 6.2) and the browser joins only when someone posts, so a human who watches and never types has no cursor to report. The feature would measure the attention of every agent and of no human, in a product whose third principle is that the humans are the ones watching.
 - A receipt must never be an item. An append allocates a `seq` and publishes on the wake topic, so every receipt would wake every poll, and every woken poll returns and reissues with a new cursor, which is another receipt. The loop does not settle. Receipts have to be participant state carried on responses that were going to happen anyway, and for the same reason they must not publish on the wake topic even as state.
 - Freshness is inverted relative to what a reader will assume. There is no push, so a cursor is only as current as the last poll. During an exchange it is accurate to the second, because a returning poll is reissued immediately. It goes stale exactly while an agent is away doing the work the message asked for — the moment its peer is most likely to read "has not seen it" as "is not there". Presence has the same defect and is honest about it by collapsing into three words; a precise number invites a precision it does not have.
 - It is self-reported and unverifiable. `after` is whatever the client chooses to send, and an agent that skips a backlog by polling from `last_seq` reports having read all of it. That is harmless while nothing depends on the number, and it is the reason nothing ever should: no gate, no cap, and no "wait until everyone has read this" can be built on a value a participant picks.

docs/PLAN.md

@@ -126,7 +126,8 @@ There is no M4 milestone in the tracker, matching how the last two features ship
 
 - Webhooks so non-agent systems can post into a channel.
 - Channel templates with pre-written goal lines.
-- Team workspaces with accounts, if demand exists.
+- Accounts: sign-up and sign-in in Wave itself, off unless configured; the owner on the channel record; per-account limits. Decided 2026-09-30 to live here, not in a product built on Wave (PRODUCT section 15.6).
+- Team workspaces, if demand exists.
 - Encryption at rest in `standard` mode, depending on the answer to open question 2.
 
 ## Risks

docs/PRODUCT.md

@@ -16,10 +16,10 @@ Wave provides the wire. It does not provide orchestration, shared filesystems, o
 
 ## 3. Principles
 
-1. **Prompt is the installer.** A participant needs nothing beyond a shell tool that can run `curl`. No account, no SDK, no download.
+1. **Prompt is the installer.** A participant needs nothing beyond a shell tool that can run `curl`. No account, no SDK, no download. Creating a channel needs no account either. Signing in is optional, is part of Wave itself, and only gives the creator ownership of what they create (section 13).
 2. **Provider neutral.** Any agent that can make HTTP calls and loop can participate. Nothing in the protocol depends on a specific vendor.
 3. **Humans stay in the loop.** Every channel has a live human-readable transcript, and humans can post into it.
-4. **Minimal data, minimal time.** We hold only what is needed to deliver messages, and only until the channel expires or is closed.
+4. **Minimal data, minimal time.** We hold only what is needed to deliver messages, and only until the channel expires or is closed. An account, for a person who chooses to have one, holds only what sign-in needs and never a message.
 5. **Transport, not orchestration.** We never decide what the agents should do. The goal comes from each human.
 6. **Secure by default.** Every request is authorised server-side by a bearer credential. Channel IDs alone grant nothing.
 7. **Self-hostable.** Wave is open source. Anyone can run an instance, and the reference instance is one deployment among many. The protocol, the prompt, and the docs refer to the instance only as `{{HOST}}`.
@@ -40,14 +40,14 @@ Wave provides the wire. It does not provide orchestration, shared filesystems, o
 
 - Task orchestration, scheduling, or supervisor agents
 - Shared filesystem or code sync
-- Persistent agent identities or profiles across channels
+- Persistent agent identities or profiles across channels. Accounts (section 13) are for people, and an account gives an agent nothing
 - Message history beyond the channel lifetime
 - Human-to-human chat as a primary purpose
 
 ## 5. Roles and vocabulary
 
 - **Channel**: a temporary room with a fixed mode, expiry, and participant cap.
-- **Creator**: the human who creates the channel in the browser. Holds the admin token.
+- **Creator**: the human who creates the channel in the browser. Holds the admin token. A signed-in creator is also recorded as the channel's owner (section 13); the admin token keeps working either way.
 - **Invite**: the secret that lets a participant join. Embedded in the prompt and in the channel URL fragment. Anyone holding it can join and read.
 - **Participant**: an agent or a human who has joined. Has a display name, a role (`agent` or `human`), and a participant token.
 - **Message**: a text item posted by a participant.
@@ -610,13 +610,17 @@ Rate-limit responses use 429 with `Retry-After`.
 - Counters: seq, item bytes.
 - Idempotency keys for posts, 5-minute TTL.
 
+### Stored per account
+
+Only on an instance with sign-in configured, and only once accounts ship (section 13): the sign-in record, its sessions, and the ids of the channels it owns. Never a message body, and nothing about channels the account does not own.
+
 ### Retention policy
 
 - Every key carries a TTL equal to the channel expiry. Nothing survives expiry.
 - Close deletes every key for the channel synchronously.
 - Message bodies never appear in application logs, error reports, or analytics.
 - Abuse counters use a salted hash of the IP with a 1-hour TTL.
-- No accounts, no cookies beyond what the creator's browser needs to hold its admin token locally.
+- No cookies beyond what the creator's browser needs to hold its admin token locally, plus the session cookie of a person who chose to sign in (section 13). An instance with sign-in off sets neither an account nor a session.
 - The storage provider must be configured without long-lived snapshots of channel data, or with snapshot retention no longer than the maximum channel TTL. This is a provisioning requirement, checked before launch.
 - Product analytics are limited to counts and durations. No text, no names.
 
@@ -697,9 +701,10 @@ Technical design lives in [ARCHITECTURE.md](ARCHITECTURE.md). Summary: one Next.
 
 ### Later
 
+- **Accounts.** Sign-up and sign-in built into Wave itself, off on any instance that does not configure them (section 15.6). A signed-in creator owns the channels they create; ownership is what invite rotation, kick, and per-account limits attach to, and `wave login` signs a person into the CLI the same way. Participants still join by pasting the prompt, with no account. Nothing that needs an organisation belongs here.
 - Webhooks so non-agent systems can post into a channel
 - Channel templates for common use cases with pre-written goal lines
-- Team workspaces with accounts, if demand exists
+- Team workspaces, if demand exists
 
 ## 14. Success metrics
 
@@ -801,6 +806,35 @@ names, from which client, and when each message was sent and how large it was. I
 cannot see what any message says.** Anyone who cannot accept that list should not be
 told `e2ee` covers it.
 
+### 15.6 Accounts belong in Wave
+
+**Sign-up, sign-in, sessions, and the owner on a channel record are Wave features, in
+the open. Decided 2026-09-30.**
+
+The alternative was to leave every trace of identity to a product built on top of Wave.
+That kept core small, but it meant a self-hosted instance could never have a creator who
+owns anything, and it put the code that most needs review where nobody outside could
+read it. Person identity is good structure on its own: the owner on a channel is the
+natural thing for invite rotation, kick, and per-account limits to attach to, and a
+`wave login` in the CLI is the natural thing for anything that must be approved by a
+person rather than an agent.
+
+What this settles:
+
+- Identity is built, not bought. A vendor inside Wave would give every self-hosted
+  instance a vendor dependency, which principle 7 forbids. Passkeys or magic links, with
+  an optional OAuth adapter, are the shapes that fit.
+- It is off by default. An instance with no sign-in configuration runs exactly as
+  before, and the prompt and the join flow never change. Principle 1 is kept in full.
+- The API stays bearer-only. A session cookie is for the browser; API routes take the
+  same channel credentials as today, so nothing about CSRF changes for agents.
+- Organisations, membership, roles, and anything that needs a durable store beyond a
+  channel's life are not core. Core stores an account and what it owns, nothing about
+  who else the account works with.
+
+**Revisit if:** sign-in turns out to need a store Redis cannot be, or an instance
+with sign-in on cannot be run with the same two services as one with it off.
+
 ## 16. Validation, and what it found
 
 The plan below was written before the build and has since been carried out. It is kept