fix(notifications): use a local device profile without wallet login

[0xApotheosis]

Description

Create a notification profile silently from a device key stored in IndexedDB. Reloads reuse that identity; separate browser profiles get separate identities. Public wallet addresses are no longer used to retrieve or merge user profiles.

Keep session tokens in memory, renew expired sessions automatically and complete mobile registration only after receiving the native push-verification proof.

What this affects

The trading app's background device-profile and notification registration, in desktop browsers and the mobile WebView. It creates a local device identity without a wallet-login signature. Clearing site data creates a new identity; connecting the same wallet in another browser does not restore the old profile. There is no new profile/history screen to inspect.

Issue (if applicable)

No linked issue.

Risk

High: changes profile registration and requires the companion user/notification services and mobile handler. Clearing local storage creates a new profile and does not recover previous history. No wallet signature prompt is introduced.

Deployment and QA environment

Ship/test together: user-service #68, notifications-service #69, web #12742, and mobile #166 + #165. Engineering prepares a combined integration build and resolves their shared-module/migration conflicts before QA. Apply the shared security_limits and device_auth migrations once to an isolated PostgreSQL database; run migration/concurrency tests against that database.

Backend environment: The Railway microservices project currently has develop and production, with no separate PR environment. Engineering must create an isolated QA environment for this bundle and post its service/deployment links. Deploy user-service and notifications-service there, plus swap-service with the updated internal caller code and matching server-only SERVICE_API_KEY. Configure exact app origins, NOTIFICATIONS_SERVICE_URL, and trusted ingress peers where required. The checked develop user-service configuration did not yet include DEVICE_ALLOWED_ORIGINS or NOTIFICATIONS_SERVICE_URL; an existing develop deployment is not sufficient evidence that this bundle is ready.

Client environment: Deploy web #12742 to an assigned beard/juice QA slot, point VITE_USER_SERVER_URL at the QA user-service, and enable WebServices. Supply native internal builds of #165 + #166 whose configured trusted origin is that same QA web URL. Ordinary security/* web branches do not automatically deploy. Use disposable wallet/device profiles and test push recipients.

Release: Repeat the web checks on release with the intended service configuration and repeat native checks on release-candidate binaries. Provision the production schema/configuration first, make compatible native builds available, then coordinate backend and web activation. Old native clients cannot complete the new proof exchange. Record the supported native version and how older clients will be handled before release; independently deploying one component is not a complete rollout.

QA handoff: Environment inventory was checked on 9 October 2026. Before Operations starts, Engineering posts the exact app/install links, deployed commit/build numbers, test fixtures and readiness confirmation in this PR. Operations records the browser/device, steps passed/failed and screenshots of failures. Environment preparation and tests described here are a plan, not a claim that deployment or live QA has already happened.

Testing

Engineering

Validated locally: 5 device-key persistence/signature and API tests, full lint and TypeScript passed. Lint reports 9 existing warnings.

With Node 22 and pnpm, install dependencies and build workspace declarations first, then run:

pnpm exec vitest run src/lib/user/api.test.ts src/lib/user/deviceIdentity.test.ts
pnpm run lint --fix
pnpm run type-check

The tests use browser-storage and native-bridge mocks. Supported WebView persistence and real push delivery still need device QA.

Integration/security checks — Engineering

The checks below require service configuration, API tools or backend observation. Engineering owns them; the click-through Operations checklist follows. Any environment setup mentioned here must follow the deployment plan above.

1. Point VITE_USER_SERVER_URL at the companion backend, enable WebServices and connect a test wallet. Confirm profile creation completes without requesting a wallet signature.
2. Reload and reopen the same browser profile. Its user ID must stay the same. Open an isolated profile with the same wallet; it must get a different user ID and must not inherit history.
3. Inspect network requests. Profile creation must use the device public key/proof; it must not submit wallet addresses to retrieve an existing user. Private device keys must not leave IndexedDB and session tokens must not be written to localStorage.
4. Expire/revoke the session, then request the profile. The client should renew once and retry successfully; a persistent authorization error should surface rather than loop.
5. On the companion native build, register for notifications with the app open. Confirm registration completes only after the matching push proof. A missing or expired proof must not report success.
6. Clear local storage/IndexedDB and repeat. Confirm a new profile is created, with no automatic access to old history.

Operations

Open: Engineering's web QA URL in two separate browser profiles, A and B. Engineering enables WebServices and records the backend profile IDs during the test. Use the supplied disposable wallet.

1. In A, connect the test wallet. The app should load normally without an extra signature request for device-profile creation.
2. Refresh, close the tab and reopen the app in A. The app should remain usable. Engineering confirms the same device profile was reused.
3. In B, open the same app and connect the same test wallet. There should still be no login signature. Engineering confirms B has a separate profile despite using the same wallet.
4. In the paired native build, allow notifications and keep the app open while Engineering confirms registration. A normal prepared test notification should arrive; the silent verification should not display a banner.
5. In the disposable browser profile only, open the browser's site settings for this QA URL and clear its site data. Reopen the app and reconnect the test wallet. The app should work again; Engineering confirms a new profile was created without inheriting the old profile's records. Keep the supplied test-wallet recovery details available before clearing data.
6. While the app remains open, Engineering expires the test session. Reload when instructed. It should recover without a wallet-login prompt or endless retry/spinner.

Pass: Normal use, persistence and renewal work. Engineering supplies evidence of identity separation and storage behavior; profile IDs and backend history are not visible in the app.

Related PRs

• fix(users): isolate profiles with device credentials microservices#68 — isolate profiles with device credentials
• fix(notifications): authorize device reads and internal sends microservices#69 — authorize device reads and internal sends
• fix(mobile): verify push-token delivery during registration mobile-app#166 — verify push-token delivery during registration
• fix(mobile): bind wallet bridge requests to the trusted app mobile-app#165 — bind wallet bridge requests to the trusted app

Screenshots (if applicable)

Not applicable; verification focuses on requests, authorization and existing flows.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}