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

[NotASithLord]

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 feat(credentials): "use but can't see" — DPoP proof-of-possession + a non-extractable vault key #298 — an unusually strong credential design. This is not exploratory code.
2. "Safe for broad public use, with stated limitations." Close. Blocked on P0-1.2: no isolated host ⇒ no untrusted-content actor. Decide the Firefox contract (1.0 blocker) #305 (the Firefox isolation contract) and Define and test the lifecycle contract: what survives eviction, restart, and upgrade #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 (P0-2 remainder: per-run MessagePorts, and actor/abort takes a runId from any first-party sender #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 (P0-1.2: no isolated host ⇒ no untrusted-content actor. Decide the Firefox contract (1.0 blocker) #305).
2. A stable data/vault/session migration contract (Define and test the lifecycle contract: what survives eviction, restart, and upgrade #306).
3. Documented interruption and retry semantics (Define and test the lifecycle contract: what survives eviction, restart, and upgrade #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.

[NotASithLord]

Decision on the positioning question

Owner's call: pursue the Firefox isolate if there is a genuinely low-hanging path; otherwise proceed without holding Firefox to the same maturity tier.

The #305 spike came back: the design is elegant and better than Chrome's, but it is not verifiable today — peerd cannot execute Firefox in any lane (#310). An isolation claim that cannot be proven is worse than an honestly labeled fallback, because it would let us stop flagging the weakness without earning the right to.

So the answer to this issue's open question is the split label:

peerd 1.0 for Chromium — Firefox preview/experimental

That reflects the code as it stands: 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.

What this changes in the blocker list

Blocker 1 ("no bound hostile-content actor in the privileged SW heap on any browser called stable") is now satisfied by scoping rather than by fixing — Firefox is not called stable, so it does not need the isolate to ship. #305 moves out of the 1.0 blocker set and becomes the path to re-including Firefox at tier 1 later, gated on #310.

The remaining 1.0 blockers are unchanged: the migration contract and interruption semantics (#306), security CI actually enabled, an independent review of the privileged core, and no known critical/high issues in the defined threat model.

Two things this makes load-bearing

1. The label has to appear where users and reviewers actually look — store listing, README, the AMO description, and the threat model — not only in this issue. A split maturity claim that is only tracked in the issue tracker is the same failure mode as burying it in a residual.
2. P0-1.1: bound actors on the in-SW fallback never got keyless custody (Firefox) #304 changes character. Keyless custody on the bound-actor fallback was a stopgap when the isolate was imminent. With the isolate deferred, it becomes the primary hardening Firefox actually gets, and is worth doing on its own merits — it removes live credentials from a loop frame that ingests untrusted content, which is real even without heap separation.

---

Generated by Claude Code