Skip to content

chore: README + deploy under EffectStream Cloudflare account - #1

Open
acedward wants to merge 5 commits into
mainfrom
chore/effectstream-deploy
Open

chore: README + deploy under EffectStream Cloudflare account#1
acedward wants to merge 5 commits into
mainfrom
chore/effectstream-deploy

Conversation

@acedward

@acedward acedward commented Jun 5, 2026

Copy link
Copy Markdown

Summary

  • Add README explaining what the project does, how it's built, how to run locally, how to deploy, and how to test (both standalone and as an embedded iframe)
  • Update wrangler.jsonc to deploy under the EffectStream Cloudflare account (worker name wallet-passkeys, new KV namespace IDs); drop the upstream rvcas custom-domain route
  • Already deployed: https://wallet-passkeys.ac-edward.workers.dev

Test plan

  • pnpm install && pnpm dev brings up the dev server (Worker + React app via @cloudflare/vite-plugin)
  • pnpm run deploy pushes a new version to wallet-passkeys.ac-edward.workers.dev
  • Visit the deployed URL, click Register, complete the OS biometric prompt — DID Document is shown
  • Embedded usage works from a different origin (see companion repo effectstream/wallet-passkeys-app)

acedward added 5 commits June 4, 2026 22:35
* Add README.md covering what the project does, architecture, local-dev
  workflow, build/deploy commands, KV namespace IDs, manual testing via
  the embed iframe, and security caveats
* Update wrangler.jsonc:
  - account_id: EffectStream (28ea08e3…) instead of rvcas (864bff2c…)
  - name: wallet-passkeys (was passkeys) so the workers.dev URL matches
    the GitHub repo name
  - drop the rvcas custom_domain route; the workers.dev URL is sufficient
  - kv_namespaces: new IDs created on this Cloudflare account
    - CHALLENGES:  11f31ec5555e4f58afc922748bff0438
    - CREDENTIALS: ecc0c8045cbe47c5bf542521ec5940d7

Live at https://wallet-passkeys.ac-edward.workers.dev
… corners

The iframe consumer (wallet-passkeys-app) is being restyled in parallel with
a deliberately opposite visual language. Together they make the iframe
boundary unmistakable when the wallet pops up inside the dApp.

Theme:
* :root + .dark CSS variables redone in OKLCH: near-black background,
  phosphor-green foreground/accent, neon-green primary
* --font-sans / --font-heading / --font-mono all → "JetBrains Mono"
* --radius: 0.125rem (sharp 2px corners, no soft rounding)
* Subtle scanline gradient on body, soft phosphor-glow on primary buttons

Components:
* header.tsx — "wallet-passkeys" wordmark with green/dim-green split + "auth
  provider" eyebrow
* embed-auth.tsx — terminal-prompt strip ("$ wallet-passkeys connect") at the
  top of both the unauth and authenticated states; [OK]/[WARN]/[ERR] prefixes
  on status lines; uppercase tracked labels; mono inputs
* index.html — JetBrains Mono via Google Fonts CDN; title now "wallet-passkeys
  · auth provider"

Builds clean with `pnpm run build`. Already deployed to
https://wallet-passkeys.ac-edward.workers.dev
…ositives)

After the editorial restyle of wallet-passkeys-app, the iframe wrapper there
gained a heavy 3px border and an offset orange box-shadow (.wallet-popup-frame
in the dApp). Chrome's experimental IntersectionObserver({trackVisibility:true})
API treats those wrapper styles as "visually obscuring" the iframe even though
the iframe content is fully visible — so the embed kept showing
"[WARN] iframe obscured · auth will open in a new window" and switching
register/sign-in to popout mode.

The trackVisibility API is poorly documented, Chrome-only, and has a long
history of false positives in dev. As a security check it provides little
benefit — a real attacker can hide the iframe with dozens of other
techniques the API can't detect. Better to rely on:

* `Content-Security-Policy: frame-ancestors *` (already set by the worker)
* Per-message origin pinning on postMessage (already in the protocol)
* CSP/CSRF on the API side
* OS biometric prompt being unspoofable by definition

Replaced the hook with a no-op stub that always reports visible=true. No
other behavior changes; if we ever want a real anti-clickjack signal we
should look at top-level redirect + popup instead of trying to detect it
in-frame.
User-facing strings only; postMessage source identifiers and
localStorage keys are left as "midnightos-*" so the lockstep protocol
contract with wallet-passkeys-app stays compatible.

* passkey-demo.tsx headings: "midnightOS Passkey Demo" → "EffectStream
  Passkey Demo" (both authenticated + unauthenticated views)
* worker RP `name` in register/authenticate/authorize-key.ts:
  "midnightOS Passkeys" → "EffectStream Passkeys". This shows in the OS
  biometric prompt as the relying party label. Safe to change — the RP
  *id* (origin) is unchanged, so existing passkeys keep working.

Deployed: https://wallet-passkeys.ac-edward.workers.dev
… footer

The /embed route now renders as a full-height browser-extension-style
wallet panel instead of a loose form:

* .wallet-shell — fixed-height flex column (header / scrollable body / footer)
* Header: "ES" mark, "EffectStream Passkeys / wallet · auth provider", and a
  live status pill (LOCKED → CONNECTED with a pulsing green dot)
* Body: a "Connection request" approve card (mimics a wallet's review panel),
  username input; on success, a "Wallet connected" card + truncated did:key
  account row
* Footer: action buttons pinned to the bottom — Cancel / Sign In / Register
  before auth, a single OK after. Cancel/OK postMessage `close` so the parent
  dApp can dismiss the floating popup.

The parent (wallet-passkeys-app) floats this iframe top-right like a browser
wallet, so the chrome reads as a real wallet popup.

Built clean with `pnpm run build`. Deployed to
https://wallet-passkeys.ac-edward.workers.dev
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant