Spike: Deckard-native dapp bridge (PRD-04 #1) #49

Re-scoped 2026-07-10 → ADR 0006 (via #202). Since this spike was written, a hand-rolled 127.0.0.1:8765 loopback bridge shipped (#62/#63/#139/#141/#146/#148/#198) and is accepted as the temporary, experimental alpha transport — it is not the end state and gets no further hardening. Native messaging remains the post-audit target, so open choice (a) below is about the replacement wire, not the alpha's. Task 5's localhost contrast can use the shipped bridge as a live specimen.

Part of #44 (ADR 0001). First deliverable of PRD-04. Standalone spike — do not touch crates/ or ship anything user-facing.

Goal

Prove (or disprove) that a first-party, key-less browser connector can give Deckard universal dapp reach over a wire Deckard owns end-to-end (no third-party relay, no embedded browser, no store as a trust anchor), and settle two open choices: (a) the local wire (native messaging vs hardened localhost) and (b) the self-distribution path, on both Chromium and Firefox.

Context (verified in research — don't re-litigate)

• Dapps speak EIP-1193; inject a standard provider announced via EIP-6963 (research §7, 21–22).
• Native messaging is the leading wire: OS-installed stdio host gated by manifest allowed_origins/allowed_extensions, runs as the user, not web-reachable (§3, 12, 15).
• A localhost RPC port is web-reachable (DNS-rebinding / cross-site WS hijacking); needs origin-allowlist + token + Host checks and is still weaker (§1, 2).
• MV3 service workers are ephemeral; connectNative keeps the port alive but reconnect on onDisconnect (§5).
• Trust is bounded by design, not the store: a key-less connector, even fully compromised, can only propose — never sign/self-approve/exfiltrate a key (§6, 22, 29). This is why self-signed off-store distribution is acceptable.
• Mirror deckard-mcp (docs/build/30-mcp-shape.md); use deckard-contract's MockSigner (no real key).

Tasks

1. Mock host + mock daemon: a small Rust bin (spike's deckard-bridged stand-in) speaking native-messaging stdio framing (32-bit native-endian length + UTF-8 JSON, §12) on one side and the deckard-contract wire to MockSigner on the other. Map eth_requestAccounts→Address, personal_sign→mock sign, eth_sendTransaction→Propose/Status/Execute. Standalone crate spikes/deckard-bridge/ with its own [workspace]; .gitignore target/+Cargo.lock; depend on deckard-contract by path. No real key/signing/broadcast.
2. Minimal connector (Chromium MV3 + Firefox; separate manifests): inject EIP-1193, announce via EIP-6963 (rdns e.g. sh.deckard), relay page JSON-RPC → background → native-messaging port → host. Handle MV3 SW reconnect.
3. Drive a real dapp end to end: eth_requestAccounts + one personal_sign, on Chromium and Firefox.
4. Stress MV3: force SW eviction mid-session; confirm reconnect + success.
5. Prove web-unreachability of native messaging (no port to reach from a page); contrast: show a localhost fallback can be reached cross-origin without defenses, and that token/Host checks block it.
6. Self-distribution dry run: signed Firefox XPI installed from a self-hosted URL (not AMO listing); Chromium self/sideload path + friction, documented.

Constraints

Standalone spikes/deckard-bridge/; don't edit crates//app. Key-less throughout; no real broadcast. No secret in any log/message (grep assertion).

Success criteria / report

YES/NO on "native messaging carries a full EIP-1193 round-trip cleanly on both browsers with reliable MV3 reconnection," + a wire recommendation (with the §5 security evidence), + a self-distribution recommendation (exact Firefox + Chromium paths + friction), + a runnable spike. Return a <spike_report> with: wire_verdict, native_messaging, web_unreachability, distribution, eip6963, what_worked/failed, recommendation (one paragraph for PRD-04), artifacts.

(The full spike brief was drafted at spikes/deckard-bridge-spike.md on branch claude/wallet-security-dapps-extension-jzlxj7; per the issues-for-work-items convention it now lives here.)