Per-user content and user@host: the last two headline questions

NOTES.md

@@ -191,6 +191,22 @@ Static-only dividends worth actively exploiting:
 - **Push without a server** (see
   [Compute placement and push](#compute-placement-and-push)).
 
+**Per-user content: answered.** Recorded 2026-08-26 from design
+discussion; direction, not final ruling. The home origin serves
+per-user content **never by default**: the byte-identical model above
+is the trust story, and a host that can serve one user different
+bytes is a host that can target them — the accountless dividend and
+the constant-digest monitoring predicate
+([Release integrity](#release-integrity)) hold precisely because
+there is nothing user-specific to vary. Where per-user serving exists
+at all, it is an **explicit opt-in to a lower trust regime** — the
+"third origin class" already named under
+[Addressing and discovery](#addressing-and-discovery): live-ish,
+user-controlled, untrusted, never sharing the framework origin. The
+expectation on record: this opt-in is a **developer-oriented option**
+(publishing one's own records and content) rather than an end-user
+surface; users who never opt in keep the full trust story untouched.
+
 ## Release integrity
 
 Positioned as supply-chain hygiene and publisher/host separation — not
@@ -1113,6 +1129,23 @@ feature — a reason to surface compute placement as a powerbox decision
 Y"), defaulting to user-owned always-on nodes (old laptop, phone
 runtime), which component-iroh's deployment matrix was built for.
 
+**Usable without the powerbox.** Recorded 2026-08-26 from design
+discussion; a goal, not a v1 ruling. At least many apps must be
+**usefully usable with no headless copy anywhere** — either because
+they implicitly don't depend on always-on sync (local-first by
+temperament, single user, one device at a time), or because
+**asynchronous sharing through a storage backend** covers their
+collaboration: the bucket path — ciphertext put/pull, offline
+authoring reconciled later, cold-start from the bucket alone — is
+exactly the machinery
+[Storage backends](#storage-backends-and-the-cryptographic-pull-layer)
+builds and the #20 demo proves. The powerbox decision above is an
+enhancement for apps that genuinely need liveness, never a
+prerequisite for ordinary use; a design where basic collaboration
+silently assumes an always-on peer is out. What stays open is only
+the smaller question: whether the powerbox version itself ships in
+v1 at all.
+
 Push, keeping the origin static: **the subscription is a capability.**
 Web Push senders need only the subscription endpoint + VAPID key —
 hand them (encrypted) to your contact group over the sync layer and
@@ -1406,6 +1439,24 @@ the origin. Options:
   model.
 - Nothing in v1.
 
+**Answered: deferred, with a guard.** Recorded 2026-08-26 from design
+discussion; direction, not final ruling. "Nothing in v1" is the
+selection — contact exchange stays out-of-band (QR / links through
+the sharing layer) — **unless deferral would preclude the feature
+architecturally**, which is the actual content of this ruling: nothing
+built in the meantime may foreclose `user@host` later. What the guard
+means with today's vocabulary: the per-user static records option
+stays adoptable (per-user serving is already specced as an opt-in
+lower trust regime — see
+[Home origin contract](#home-origin-contract) — and a discovery record
+would be a developer/user opt-in of exactly that class); contact cards
+remain self-certifying artifacts whose delivery channel is orthogonal,
+so a host-served record later is a new transport for the same bytes,
+not a new format; and first-contact verification ceremonies bind
+regardless of how the card arrived, so a future host-served
+introduction path inherits the existing backstop against prekey
+substitution rather than needing a new one.
+
 Related: the static share-link viewer (reader page + ciphertext + key
 in fragment) covers "share with a non-user" without discovery
 infrastructure.
@@ -2519,7 +2570,10 @@ Tracked as issues; the headline ones, verbatim from the discussion:
 - Target app developer — answered: component-native, with a real
   porting on-ramp and no drop-in promises; see
   [Developer experience](#developer-experience).
-- Is headless-at-provider execution in scope for v1?
+- Is headless-at-provider execution in scope for v1? — narrowed: at
+  least many apps must be usefully usable with no headless copy at all
+  (see [Compute placement and push](#compute-placement-and-push));
+  only whether the powerbox version itself ships in v1 stays open.
 - Does Safari have to work at launch — answered: no; see the Browser
   floor note in [The substrate](#the-substrate) (a future JSPI + wasm
   multi-memory Safari, hoped early 2027).
@@ -2528,5 +2582,11 @@ Tracked as issues; the headline ones, verbatim from the discussion:
   defaults to a public relay instance (split view preserved);
   full-stack self-hosting bundles its own and skips the public
   default.
-- Does the home origin ever serve per-user content?
-- `user@host` discovery: wanted, or out-of-band only?
+- Does the home origin ever serve per-user content? — answered: not
+  without an explicit opt-in to a lower trust regime, expected to be a
+  developer-oriented option rather than an end-user surface; see
+  [Home origin contract](#home-origin-contract).
+- `user@host` discovery — deferred: out-of-band only for now, with the
+  explicit guard that nothing built meanwhile may preclude it
+  architecturally; see
+  [Addressing and discovery](#addressing-and-discovery).