Skip to content

Browser demo recipe: connect → attributed approval → per-site revoke (#29 pattern) #201

Description

@hellno

Part of #44. The browser-track demo deliverable, in the full #29 shape (policy + transcript + acceptance test).

Corrected 2026-07-10 (codebase re-verified): the "connect → attributed approval" spine is already on main; only the per-site-revoke finale rides on #199. The method issue-refs below were wrong and are fixed. Recommendation: ship this recipe WHOLE after #199 lands — do NOT split off a connect→approve half (see "Why not split").

Goal

A rehearsable, acceptance-tested demo: a human drives a site in the browser; every ask renders in Deckard attributed to the right origin; the demo ends by killing the site's access.

What already works on main (verified 2026-07-10)

The bridge forwards and clear-signs the full method set, and #198 attributes each to the site:

(The original body cited #137/#138/#142 — those numbers were wrong; the features landed under #139/#141/#146/#148.)

What is still missing

  • Fixture dapp (examples/browser-bridge-dapp/index.html) has ONLY eth_requestAccounts + eth_chainId buttons (index.html:19-20). Add buttons for personal_sign, eth_sendTransaction (small ETH send to a fork address), and an ERC-20 approve (exercises the feat: classify ERC-20 send transactions #146 classified card). Deterministic and offline-on-fork by decision — no third-party dapp (repeatability beats realism here).
  • The Scenario recipes: policy variants with transcripts, each backed by an acceptance test #29 triple: policy.browser-demo.json (or reuse policy.demo.json) + a click-by-click transcript with expected UI states + an acceptance test against the mock daemon covering each policy decision.
  • just demo-browser: wires the demo world + bridge + fixture server. The bridge MUST inherit DECKARD_SOCKET_PATH/DECKARD_CHAIN_ID from the launcher (docs/browser-bridge.md) or it dials the wrong vault. (Today only just demo-bridge/qa-bridge exist.)
  • Per-site revoke — the closing beat — needs Connections: daemon-held dapp sessions, listed in the app, revocable per site #199 (revoke() is dead code today; the Connections sidebar is a placeholder).
  • Stale-doc fix — DONE 2026-07-10: browser-bridge.md:86-88/:176 corrected.

Why not split

A "connect → approve" half-demo without #199 shows attributed cards but the Connections sidebar stays "No connected sites yet" (shell_chrome.rs:197) the whole run — the headline connect beat produces no visible artifact and the audience can't see or kill a connection, which is the exact pitch #199 exists to land. Splitting also doubles the recipe work (two PRs both editing the fixture, transcript, policy, and just demo-browser). Land #199 first, then ship #201 whole.

Demo beats (the transcript skeleton)

  1. Connect → the origin appears under Connections (Connections: daemon-held dapp sessions, listed in the app, revocable per site #199).
  2. personal_sign → card attributed to the origin (works today).
  3. eth_sendTransaction → attributed card (Dapp origin on the wire: attribute browser transactions to the requesting site #198), human approves, tx lands on the fork.
  4. ERC-20 approve → classified card shows the token effect (feat: classify ERC-20 send transactions #146).
  5. An off-policy ask → loud deny with a typed reason.
  6. ⌘K → Revoke connected site → the next call fails 4100 Unauthorized (Connections: daemon-held dapp sessions, listed in the app, revocable per site #199).

Depends on

#199 (Connections list + revoke). #198/#200 already shipped.

Acceptance

  1. just demo-browser + the transcript reproduce end-to-end on a fresh clone (given RPC_URL_SEPOLIA).
  2. The acceptance test is green in CI.
  3. Screenshots of each beat on the PR.
  4. DoD green: cargo fmt --all --check, just check, cargo test --workspace (TMPDIR=/tmp if signerd sockets hit SUN_LEN), no new/changed deps without approval.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions