# Echo Connect reference profile 0.1

This profile composes the existing HAP-1 runtime, manually paired HAP phone link and Draft Desk filesystem gate. It does not change HAP-1 signed bytes or claim a new identity protocol.

## Trust and roles

The phone owns an ephemeral, non-extractable Ed25519 issuer key and the authority store. The computer Node process owns ephemeral delegate and executor keys. The computer browser bridges a manually confirmed WebRTC data channel to a loopback HTTP API. Each session allows one approved draft. Restart creates new keys and a new private run directory, never an implicit recovery or replay. Durable journal entries survive for investigation; they do not cause execution on reopening.

Signaling uses the existing `HAP-1/phone-pair` schema, no ICE servers, and a comparison code over both descriptions and the public keys. Both ends must confirm. Public keys authenticate that paired session, not a real-world identity. Human approval is an explicit UI action on the phone; signatures are not proof that a conscious human was present. Both origins, both browsers, the Node process and host OS remain trusted.

## Two phases

1. **Review, up to ten minutes.** The executor signs `ECHO/connect-review/1` with `session`, `revision` (32 lowercase hex), `payload` (`ECHO/draft/1`), `createdAt`, `expiresAt`, `executorPublicKey`, `delegatePublicKey`. The signature domain is the schema plus a newline plus canonical unsigned JSON. The phone validates the paired keys, signature, time bounds, UTF-8 and fixed payload grammar. It retains the previous request for comparison, rejects repeated revisions, and allows at most 64 reviews. The UI reads a snapshot; approving requires that exact review hash. Untrusted draft text is rendered with `textContent`, never interpreted as markup or an instruction to the application.
2. **Dispatch, at most five seconds.** On explicit approval, the phone signs a HAP grant: capability `save-draft`, resource `draft-outbox`, pinned executor audience and delegate, exact byte allowance, `utf8-bytes`, `maxUses: 1`, `freshnessMs: 5000`, expiry no later than the review deadline and no later than two minutes after approval. The computer prepares its existing signed challenge. The phone checks the challenge digest against the reviewed payload (including operation ID), amount, ticket and HAP signatures before issuing the permit. No long-lived permit is held during reading.

The app multiplexes existing phone-link methods: `sync` for review/approval/refusal/result/evidence; `check` for the bounded HAP request; `revoke` for signed withdrawal. RPC acknowledgment means message handling, not completed filesystem effects. Incoming app messages are role-limited. The phone exposes no remote grant/private-key method.

## Gate and journal

The computer verifies the grant and persists the trusted issuer/executor/ticket pin before invoking Draft Desk. Draft Desk durably claims an operation as UNKNOWN before authorization, checks HAP freshness and revocation, then synchronously creates only `outbox/OPERATION.txt` with exclusive creation/no-follow and private permissions. Repeating a claimed operation reads its stored outcome and never writes again. Different content cannot reuse its operation. Connect additionally refuses any new approval or review after its grant. Gate/state failures are not treated as fresh allowance.

Use the unchanged `ECHO/draft-result/1`, `ECHO/draft-evidence/1` and `ECHO/draft-pin/1` schemas and Python verifier. Successful result display requires an executor signature bound to the reviewed payload, ticket, known permit and output hash. It remains an executor attestation until actual output is independently compared. A lost result leaves the phone without confirmed completion. No automatic effect retry exists.

## Withdrawal

The phone stops new permits locally before requesting remote acknowledgment. The executor validates the signed HAP revocation chain, applies it to the durable gate, and writes an acknowledgment before returning it. The acknowledgment is signed under `ECHO/connect-stop/1` over `session`, `reviewHash`, `bundleHash`, `status: RECEIVED`. The phone verifies the pinned executor signature and exact revocation hash. Export history is monotonic: a delayed permit response cannot replace newer revocation history.

Acknowledgment confirms this executor's handling, not universal cessation. Already completed files remain. A previously issued permit can remain usable during its five-second freshness window until a revocation reaches the gate. Revocation after the final synchronous dispatch check cannot undo the effect.

## Loopback boundary

The server binds `127.0.0.1` only on an automatically chosen port. Every request checks the exact Host; supplied foreign or null Origins are refused. API calls require an unpredictable 256-bit session header. Mutations require an exact local Origin and JSON content type. No CORS permissions are provided. The HTML embeds the session token under the browser's same-origin protection, frame embedding is denied, and static files use an explicit allowlist. Request bodies are bounded to 64 KiB, pending calls to eight, and requests expire. Old reply IDs cannot be reused. No endpoint accepts arbitrary file paths or executes commands.

The local API is not a sandbox against other processes owned by the same OS user. It is not exposed as a LAN API; the browser's confirmed WebRTC link is the cross-device boundary. The kit needs no website API for execution; the phone webbench initially loads from the hosted page. No real AI provider, external bank, robot, medical or government integration is claimed by this release.

## Verification scope

Automated Connect regression tests traverse actual controller signatures, loopback HTTP, SQLite, file bytes, signed evidence and the separate Python checker. Existing Draft Desk tests cover crash/unknown recovery, forbidden overwrite, symlinks and verifier tampering. Existing phone-link tests cover double confirmation, chunking and method constraints using a peer double. These are not physical iPhone/network tests. Source ZIP reproducibility and copies served publicly are checked in CI. No independent security audit or adoption claim follows from passing these tests.