Decision: the 1.0 contract — scope, blockers, and per-browser positioning

Umbrella decision issue. peerd is 0.4.0 and has been "0.x — experimental beta" since the start. The post-merge review of #298 argues the architecture is past the point where 0.x is doing honest work, but that an unqualified 1.0 across both browsers would overstate the Firefox posture.

This issue is to decide, not to drift.

Three different claims people hear as "1.0"

1. "The architecture is legitimate." Already true. Privileged SW reference monitor, keyless isolated actor heaps, gated tool dispatch, origin-bound credential egress, an explicit threat model with red-team invariants, a reproducible release chain, and — after #298 — an unusually strong credential design. This is not exploratory code.
2. "Safe for broad public use, with stated limitations." Close. Blocked on #305 (the Firefox isolation contract) and #306 (the lifecycle/recovery contract).
3. "Hardened for high-trust delegation." Not yet, and should not be claimed. Wants an external audit, fail-closed isolation everywhere, per-run MessagePort identity (#308), capability handles and hierarchical budgets, full WebVM root-image integrity, and real field exposure.

Conflating (1) with (3) is the failure mode to avoid. A version number is not a security ranking — a 0.x product can have a better trust model than a 1.x one while being less mature in compatibility, persistence, migration, recovery, and external validation.

Proposed path

0.9 = release candidate. Feature/security freeze, then spend it on: browser-matrix validation, vault migration testing from real existing profiles, extension-store review, crash/restart fault injection (#306), a focused external review of the privileged core, and compatibility testing against representative providers and DPoP servers.

1.0 blockers — deliberately narrow:

1. No bound hostile-content actor running in the privileged SW heap on any browser called stable (#305).
2. A stable data/vault/session migration contract (#306).
3. Documented interruption and retry semantics (#306).
4. All security CI and release-environment settings actually enabled, not merely present in code.
5. At least one independent review of the privileged core.
6. No known critical/high issues in the defined 1.0 threat model.

Explicitly 1.1–1.3, not blockers: DPoP nonces (#301, done), key rotation (#302), Merkle-streamed WebVM images, generalized capability tokens, durable distributed operation leases, taint-aware GET egress, sandbox tiers.

The positioning question

Unless #305 is solved first, the accurate label is:

peerd 1.0 for Chromium — Firefox preview/experimental

That reflects the code: Chromium has the intended actor isolation; Firefox has a materially weaker fallback for bound actors; everything else (release integrity, security testing, credential architecture, threat modeling) is approaching a legitimate 1.0.

Decide here: solve #305 and ship one uniform 1.0, or ship the split label. Both are defensible; drifting into an unqualified 1.0 without picking is not.

Read #305 and #306 first, then review the post-merge discussion in #298 and the listed 1.0 blockers. Done means recording a decision between a uniform 1.0 and the proposed Chromium 1.0/Firefox preview positioning, with the selected criteria and remaining blockers explicit.