feat: wake a closed browser, over Web Push

[Sycatle]

A browser that has Whispee closed now learns a message arrived. It was the first thing between the deployment shipped yesterday and somebody able to use this.

What this changes, and why this rather than the obvious alternative

The obvious alternative was the one the roadmap described: FCM and APNs. It said the missing half was "all of it the part that requires secrets", and that was true and it was not the hard part. The hard part is device-side registration — a Tauri plugin that does not exist, therefore Kotlin and Swift, none of which compiles or runs on this machine: no NDK, no macOS host, no device. Writing it would have produced exactly what this repository refuses elsewhere, integration code that has never been executed and looks like a feature.

Web Push removed that wall for one specific reason. The wake-up carries nothing — the third of the three limits in 0011_push.sql — so there is no payload to encrypt, so the whole content-encryption half of Web Push is unused: RFC 8291, aes128gcm, the p256dh and auth subscription secrets, all of it. What is left is one ES256 signature per push service, cached until it nears expiry.

It also needed no migration for the addresses. Without a payload the only thing worth keeping is the endpoint URL, so push::Address { provider, token } holds a subscription unchanged, and Vapid::wake matches on the provider name so FCM and APNs land beside it later without touching the call site.

One variable turns it on, and there is no private key to supply. VAPID_SUBJECT is the contact a push service is told to reach; the key pair belongs to the server and is created on first start (0020_vapid.sql), the shape log_key has had since the transparency log. The alternative — a VAPID_PRIVATE_KEY variable — means every operator produces a P-256 key in the one encoding this server accepts, and a private key travels through a shell history on its way in. Unset, Silent is the waker, the key route answers 503, and the client hides the control.

Settings became a dialog in the second commit. They were a route that replaced the centre column, so opening them made the window claim you had gone somewhere: the conversation you were reading disappeared to show a theme picker. The URL is kept — #/settings/notifications still deep-links, the back gesture still steps out of a section first — because a modal on local state would have been shorter and thrown that away. Dialog gained size="panel" rather than a second modal being written beside it: that file exists for the four things Radix does and every hand-rolled modal omits, and a settings modal built next to it would have omitted the same four invisibly.

What it does not solve

• No FCM, no APNs. The packaged mobile application is still only notified while it is open. The wall described above has not moved.
• iOS needs the site installed to the home screen before it will subscribe at all.
• The notification is generic. "New message", nothing else. The worker cannot decrypt — the MLS keys are in the page's memory, not the worker's — and moving them would hand the decryption keys to a context that outlives every tab.
• Push degrades sealed sender, and nothing cryptographic answers it. A server that stops waking four members of five makes the next post attributable to the fifth.
• No test can establish that Google and Mozilla accept these tokens. The suite checks the token against RFC 8292 and against the advertised key; the residual risk is a service disagreeing with that reading. There is an #[ignore]d test that pushes to a real subscription, with the command to run it, and I ran it — see below.
• The retry queue for a failed vault drop is still in memory, unchanged by this branch and still in the roadmap.

Security impact

• No security or privacy property is affected.
• A property is affected. Which one, in which direction, and what compensates:

Sealed sender is weakened wherever a deployment turns push on, in the direction §4 of the threat model already described: a server choosing whom to wake gains a targeted activity trigger. What compensates is that it is strictly optional, inert without configuration, and empty — and that the settings screen states both halves of the cost above the switch rather than under it.

This was already in the limitations table and the table needed no change: the cost did not move, only the feature's existence did. What did need changing is §4's opening, which said the server "sends nothing" — true when written, false now, and a threat model describing a live feature as inert is worse than one omitting it. That is the third commit.

The server has an outbound HTTP client for the first time. reqwest with rustls, no cookie store, no redirect following — a push endpoint answering with a redirect is not one to follow carrying a bearer token. No request is made unless the variable is set.

There is a service worker, and notifications.ts argued against one. That objection was about caching the application shell served by the server the desktop build exists to stop trusting. This one caches nothing: no fetch handler, no Cache, no precache manifest. push.test.ts asserts that rather than trusting the comment.

Invariants

• crypto-core does not depend on ratchet-lab, directly, transitively, behind a feature flag, or in a test. Nor does any other crate a user executes.
• No behaviour was added that only works in a debug build.

A second thing on this branch: errors stopped shrinking the room

Successes already landed well — portalled, animated, announced politely, expired by report.ts rather than by a timer inside the component. Errors did not: a Banner with rounded-none border-x-0 border-b-0 mounted as a flex child of the shell, so it took height from the conversation for as long as it stood, and up to four could stack.

Both halves come through ui/Toast.tsx now, on @radix-ui/react-toast. The lifetime did not move — an error still waits to be dismissed or replaced, because it usually means something is left to decide. Only the rendering did.

Radix for one reason: a message can now carry an action, and a button that appears unbidden has to be reachable by keyboard without stealing focus. That is a viewport in the tab order, a recall hotkey, and an announcement whose urgency matches the message — type="foreground" for an error, "background" for a confirmation, the same distinction Banner draws between alert and status. It also buys an exit animation, which useEntered cannot give.

The expiry stays in report.ts and Radix's own duration is Infinity: two owners of one timer is one too many.

Two things the browser pass changed, and neither would have surfaced any other way:

• The action was wired nowhere. That would have shipped a path never executed — the thing this repository refuses. It is on the failing poll now: "Retry" does at once what the thirty-second timer would have done, and a second failure replaces the message rather than stacking.
• Radix's label prop reaches no attribute in 1.2.23. Its types accept it and the documentation calls it the accessible name; the rendered <ol> carried tabindex and class and nothing else. aria-label is set directly instead, checked in the browser rather than assumed.

What was run

• cargo test --release — 425 passed, 0 failed
• cargo clippy --workspace --all-targets --release -- -D warnings — clean
• wasm-pack test --node crates/crypto-wasm — not run: no crypto and no WASM changed on this branch
• cargo test -p server --release with docker compose up -d — including the six new tests/webpush.rs
• pnpm run typecheck, pnpm test (721), pnpm run lint in apps/web
• Verified by hand, and this is the half that separates the feature from a hope:
  • Chrome subscribed through fcm.googleapis.com against the advertised key;
  • the server signed and pushed, and Google accepted it — no refusal logged, the subscription survived;
  • the service worker showed {title: "Whispee", body: "New message", tag: "whispee-wake"} with the tab closed;
  • the settings switch subscribed and registered the address server-side (checked in push_tokens), and unsubscribed both halves on the way back;
  • the settings dialog opened over a conversation, Escape closed it and landed back in that conversation, and a direct link to a section opened it with the focus inside;
  • WEBPUSH_ENDPOINT=… cargo test -p server --release --test webpush -- --ignored against a live subscription: Google answered 201 Created. That test is ignored by default and is the only thing that can establish a real service accepts these tokens — every other one checks this server against RFC 8292 as we read it, and a service disagreeing with that reading would pass them all. Mozilla has not been tried;
  • the feedback channel, on all six points of its plan: a confirmation expires by itself, an error persists and is cleared by the next successful poll, one <li> remains after several failures and a retry, the toast draws above the settings dialog — which matters more now that settings are one — the focus is not stolen and the Retry button is reachable, and the announcing region is aria-live="assertive" for an error against polite for a confirmation.

Found while doing that: two toggles a second apart left the switch claiming this browser would be woken with nothing subscribed, and the reverse after — subscribing and unsubscribing both reach the push service and finish in an order nobody chose. The displayed state is now read back from the browser instead of inferred from the call, and toggles are chained so only one is in flight. The read-back I re-checked in the browser; the chaining I did not, because a second Vite on this machine and a shared browser took the tab away.

Migrations

• No SQL migration was added or edited.
• A migration was added or edited.

0020_vapid.sql is added, not edited — no existing migration's checksum changed, so no database needs recreating. It is one row holding the deployment's P-256 private scalar, with the same singleton and length constraints log_key carries.

Checklist

• Targets dev, not main.
• Conventional Commits, one logical change per commit.
• Comments argue the why, in the pattern decision → why → what it does not solve.
• Documentation updated: README.md, docs/ROADMAP.md, docs/DEPLOY.md, docs/THREAT-MODEL.md, deploy/.env.example.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PDvUtP9fUQRwHYszVpJtnS

[chatgpt-codex-connector]

💡 Codex Review

whispee/crates/server/src/push.rs

Lines 357 to 360 in 39601f3

	"SELECT p.provider, p.token
	FROM push_tokens p
	JOIN group_members m ON m.device_id = p.device_id
	WHERE m.group_id = $1 AND ($2::text IS NULL OR p.device_id <> $2)",

Preserve mute and block suppression for closed-tab pushes

For subscribed devices with the tab closed, this query wakes every group member without considering the client's mute setting or blocked senders, and the empty push contains no group or sender information that would let the worker filter it. Consequently a muted conversation—or a blocked member in a group—still raises a system notification for every post, contradicting the existing notification semantics that explicitly make mute and blocking prevent interruptions.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Restrict push endpoints before issuing requests

Any authenticated device can submit an arbitrary http or https string through /v1/push/token, and the next message to one of its groups makes the server POST to that URL. A malicious member can therefore target loopback, cloud metadata, or other private-network services and use delivery timing/status side effects for SSRF; validate endpoints against supported push-service origins or otherwise reject private/untrusted destinations before sending.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Remove subscriptions when forgetting an identity

When a user forgets an identity and creates or restores another account on the same origin, the browser retains the origin-wide subscription and this replay associates its endpoint with the new device, while the old device's server row is never removed. Both accounts then point at the same live subscription, so messages for the supposedly forgotten account continue producing notifications in the new session; the forget flow must unsubscribe and forget the old device's token before clearing its credentials.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Suppress push notifications while a client is visible

A Push API event is delivered to the service worker even when a controlled Whispee tab is open; it is not limited to the closed-tab case. Because this handler always calls showNotification while App.tsx independently creates its local notification for the same arrival, subscribed users with the app open receive a generic push notification in addition to the normal conversation notification. Check for a visible window client and skip the worker notification in that case.

Useful? React with 👍 / 👎.