Problem

Associating mailboxes with ATProto identities is the core purpose of this program, but no such step exists: mailboxes.did is set to the creator DID at creation and never displayed, edited, or enforced. Concretely:

• Account/app-password UI handlers perform NO ownership check — once real multi-user OAuth is live, any logged-in DID can manage any mailbox (single-DID dev masks this today).
• The XRPC mail.createAccount did override lets any caller claim any DID, unscoped.
• There is no handle -> DID resolution step and no PDS-hosting path for users without an identity.

Decisions (locked in discussion 2026-09-11)

• Only the tenant owner may reassign a mailbox’s DID.
• Two association cases must be designed:
  1. mailbox -> EXISTING user handle (resolve handle -> DID, bind it);
  2. mailbox -> NEW DID with sovrn-hosted PDS (create DID + host PDS).

Design questions (case 2 needs careful thought before code)

• Handle strategy: user.sovrn.at handles vs user.<hosted>.<domain> handles. The latter requires per-name resolution (DNS TXT records the tenant must publish, or sovrn serving /.well-known/atproto-did per hosted name) — weigh tenant manageability against vanity.
• Where PDS hosting lives (scope vs this issue / spaces delivery).
• Display: handles, DIDs, or both on the account page.

Proposal

• Stage A (app DB, pre-spaces): show owner DID/handle on the account page; tenant-owner-only reassign via handle input (resolve via PDS com.atproto.identity.resolveHandle; check what authbroker already offers); enforce caller DID == account DID or tenant owner on account detail + app-password issue/revoke; scope the XRPC did override to tenant owners. App DB stays source-of-truth.
• Stage B (spaces): mirror the mapping as a user record in the space-permissioned repo; defines the “second ATProto account logs in → sees/creates own mailbox + app password, accesses via IMAP/JMAP” flow.

Files (stage A)

• internal/appview/provision.go, mail_create_account.go, mail_create_app_password.go, mail_list_app_passwords.go, mail_remove_app_password.go, internal/appview/ui/handler.go, account.templ, internal/store (mailboxes.did already exists)

Acceptance

• Second ATProto login sees only its own mailboxes; can create mailbox + app password and read mail via IMAP/JMAP.
• Non-owner cannot manage another DID’s mailbox (tested).