Add Product key signature scheme

.gitignore

@@ -8,11 +8,14 @@ dist/
 .playwright*
 !.env.example
 !web/.env.example
+!web/.env.product-devnet
 !contracts/evm/.env.example
 
 web/node_modules/
 web/dist/
 web/dist-bulletin*
+web/dist-product/
+web/*.car
 web/.playwright*
 web/playwright-report/
 web/test-results/

README.md

@@ -34,20 +34,28 @@ aura lights the whole field (`web/src/styles/aura.css`).
 creates one personal `SmartRuntime` per artist, and `ArtistDirectory` indexes
 artist addresses to their runtimes.
 
-**Frontend**: Static React + Vite web app deployed to dot.li.
+**Frontend**: Static React + Vite web app deployed to Netlify and, through the
+Product profile, Bulletin/DotNS at `dotify-test01.dot`.
 
 **WebRTC**: real-time music streaming.
 
 **Socket.IO**: signaling for room discovery and SDP/ICE exchange. A future
 iteration can move signaling to statement-store style infrastructure.
 
-**Product SDK direction**: Dotify remains a standalone web app first. Product
-SDK / Playground / Humanity work is a progressive-enhancement track documented
-in
-[`docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md`](docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md).
-The current SDK snapshot is prototype/reference/unaudited and must be proven
-against Dotify's Host, key-delivery, room, and contract constraints before it
-becomes a production dependency.
+**Product SDK direction**: Dotify now has an adaptive Product DevNet build for
+`dotify-test01.dot`. It keeps standalone link-first rooms and Free listening intact,
+adds explicit app-scoped Product identity, and publishes through
+Bulletin/DotNS. The runtime hooks now sit behind typed ports with the current
+viem implementation and an experimental Product CDM/PAPI adapter boundary.
+The backend key-delivery protocol now has an explicit Product sr25519
+signature scheme that binds the Product account public key to the derived H160
+requester before access checks. The shipped Product frontend still uses the
+passkey/EVM path for protected playback until host-signed key/session requests
+are wired; contract writes also remain passkey/EVM until CDM-installed runtime
+packages and host-signed transaction evidence are proven. See
+[`docs/explanation/product-devnet-architecture.md`](docs/explanation/product-devnet-architecture.md)
+and the
+[`Product roadmap`](docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md).
 
 ## Deployed
 
@@ -69,7 +77,7 @@ becomes a production dependency.
 
 **Gateway URL** — <https://paseo-ipfs.polkadot.io/ipfs/bafkr4ibynaanfrddyjgpmut2qrcu6vdttocbp4feyw6vkgxkkhqndjksny>
 
-**DotNS name** — `dotify.dot.li`
+**DotNS name** — `dotify-test01.dev-dot.li`
 
 ## How to run end-to-end (locally)
 
@@ -118,7 +126,8 @@ npm run dev
 
 | Variable                    | Required         | Purpose                                                  |
 | --------------------------- | ---------------- | -------------------------------------------------------- |
-| `API_ORIGIN`                | Production       | Frontend origin allowed by API CORS                      |
+| `API_ORIGIN`                | Compatibility    | Singular frontend CORS origin fallback                   |
+| `API_ORIGINS`               | Production       | Comma-separated exact frontend CORS origins              |
 | `PASEO_ASSET_HUB_RPC`       | Key requests     | Paseo Asset Hub EVM RPC used for access checks           |
 | `DOTIFY_DIRECTORY_ADDRESS`  | Key requests     | ArtistDirectory address used to resolve artist runtimes  |
 | `DOTIFY_CHAIN_ID`           | Key requests     | Chain ID expected in wallet-signed key requests          |
@@ -298,6 +307,10 @@ releasing it. Gated tracks use a signed session or signed key request; the
 backend verifies the requester, resolves the artist runtime, and calls
 `musicAccCanAccess` before releasing a per-track key. If access is denied, the
 UI shows the action needed to unlock the track and plays no protected audio.
+Standalone clients sign with the default `eip191` scheme. Product-host clients
+can use `product-sr25519-v1` by signing the same canonical Dotify message bytes
+with the app-scoped Product account and sending `productPublicKey`; the backend
+derives the H160 requester from that public key before any nonce is consumed.
 
 For registered artist tracks, users without a connected wallet can play Free
 tracks. For gated tracks, they see a sign-in/unlock gate. Dev-account fallback
@@ -430,9 +443,9 @@ handle:
    and decide whether a backend read-through gateway is needed.
 4. Keep demo-mode browser-exposed Pinata/content secrets out of public
    deployments.
-5. Run Product SDK feasibility spikes: Host detection, Product account signing,
-   resource allocation, Playground/Bulletin/DotNS deployment, and PolkaVM/CDM
-   contract portability.
+5. Validate the Product host/account and Bulletin/DotNS deployment baseline,
+   then wire frontend Product-signed key/session requests, resource allocation,
+   and PolkaVM/CDM contract portability.
 6. Add a production artist dashboard on `/artists`: release drafts, edit
    metadata, royalty analytics, and profile verification state.
 7. Deploy and monitor a public signaling server for DotNS / Bulletin builds.

docs/README.md

@@ -15,6 +15,7 @@ Conceptual documents that help you understand why Dotify works the way it does.
 | [Content Protection](./explanation/content-protection.md) | All | Audio encryption pipeline, what it protects, and what it does not |
 | [Royalty Settlement](./explanation/royalty-settlement.md) | All | How DOT payments flow from listener wallet to artist wallet |
 | [Listening Rooms](./explanation/listening-rooms.md) | All | WebRTC peer-to-peer streaming, signaling protocol, known limitations |
+| [Product DevNet Architecture](./explanation/product-devnet-architecture.md) | Maintainers | Dual-host boundaries, Product account capabilities, rooms, storage, and the proposed contract port |
 
 ---
 
@@ -40,6 +41,7 @@ Runbooks for hosted configuration and production validation.
 | Document | Summary |
 |---|---|
 | [Deployment Configuration](./operations/deployment-configuration.md) | Netlify and Fly dashboard settings, secrets, catalog persistence, validation, and the update checklist for future env/config changes |
+| [Product DevNet Deployment](./operations/product-devnet-deployment.md) | Build, publish, validate, and roll back the `dotify-test01.dot` Product DevNet app |
 
 ---
 

docs/backlog/24-access-streaming-v2.md

@@ -139,12 +139,14 @@ P3 first vertical slice delivered (`agent/audio-v2-p3`):
   the browser/device validation matrix, startup telemetry export, and the
   backend read-through gateway decision.
 
-Product SDK replanning note (2026-07-14):
+Product SDK adaptation note (2026-07-26):
 
-- Product SDK (`@parity/product-sdk` 0.17.0 at
-  `2f359bba28ca72855207a0a519d4118b37b4438c`) is prototype/reference/unaudited.
+- Product SDK 0.19.1 and deploy tooling 0.13.1 remain
+  prototype/reference/unaudited.
 - Host APIs are progressive enhancement for Product containers; standalone web
   remains a supported mode.
+- Host detection, explicit Product account identity, a Product DevNet build,
+  canonical room links, and dual-origin Fly configuration are implemented.
 - Product SDK contracts use `pallet-revive`, PolkaVM artifacts, and CDM
   manifests. Dotify's current Hardhat + viem + Paseo Asset Hub EVM path needs a
   portability spike before adopting that layer.

docs/backlog/README.md

@@ -104,18 +104,22 @@ ticket 18 preview assets are consciously retired by access model v2.
 `improvement-plan.md` tracks the July 2026 review of the implementation
 against the product/technical/philosophical memory and the current Parity
 Product SDK direction. The plan is now dual-mode: standalone web remains the
-first public listening path, while Product SDK / Playground / Humanity
-integration is a gated feasibility track. Nothing in that track may imply live
-Host, Statement Store, Product account, Humanity, or `.dot` deployment support
-until the relevant spike proves the current API, environment, and security
-boundary.
+first public listening path, while the Product DevNet build adds
+`dotify-test01.dot`,
+explicit Host detection, app-scoped Product identity, and canonical
+Product-origin room links. The typed runtime ports and experimental
+Product CDM/PAPI adapter boundary are implementation preparation only; they do
+not imply Product-signed contract writes, Statement Store rooms, or Humanity
+decisions. API-side Product-signed key/session verification now exists through
+`product-sr25519-v1`, but the Product frontend still needs to send host-signed
+requests before protected playback can use that identity path.
 
 The Product SDK evidence snapshot used for this replanning is
-`paritytech/product-sdk@2f359bba28ca72855207a0a519d4118b37b4438c`
-(`@parity/product-sdk` 0.17.0), fetched on 2026-07-14. It is explicitly
-prototype / reference / unaudited code. Paseo and Summit are the live preset
-environments; Product SDK contracts target `pallet-revive` / PolkaVM CDM flows,
-not Dotify's current viem + EVM RPC path; Statement Store is useful for small
+`@parity/product-sdk` 0.19.1 and
+`@polkadot-community-foundation/polkadot-app-deploy` 0.13.1,
+verified on 2026-07-26. They remain prototype / reference / unaudited code.
+Product SDK contracts target `pallet-revive` / PolkaVM CDM flows, not Dotify's
+current viem + EVM RPC write path; Statement Store is useful for small
 ephemeral presence, not full chat, SDP/ICE, durable media metadata, or guest
 reactions.
 
@@ -160,9 +164,10 @@ on `main`. The remaining order is:
    signaling and production-env evidence are closed through #36/#37.
 3. Improve room resilience and shared-listening depth only where it preserves
    the link-first guest doctrine.
-4. Run Product SDK feasibility spikes: Host capability detection, Product
-   account signing, resource allocation, PolkaVM/CDM contract portability,
-   Playground/Bulletin/DotNS deployment, and Statement Store presence.
+4. Validate the delivered Product host/account and Bulletin/DotNS baseline,
+   then wire real CDM-installed runtime packages through the Product CDM/PAPI
+   adapter, wire frontend Product-signed key/session requests, and run bounded
+   resource-allocation/Statement Store spikes.
 5. Build live Humanity / Individuality only after the research ticket proves a
    privacy-preserving source, proof shape, address-binding story, and fallback
    UX.

docs/backlog/improvement-plan.md

@@ -62,25 +62,24 @@ Where it falls short of its own standards:
 
 ## Product SDK feasibility track
 
-This track runs in parallel with standalone hardening, but it does not block
-first sound and must not be sold as a delivered capability.
+This track runs in parallel with standalone hardening and does not block first
+sound. Only the baseline rows marked delivered may be presented as live.
 
 Product SDK snapshot used for this plan:
 
-- `paritytech/product-sdk@2f359bba28ca72855207a0a519d4118b37b4438c`
-  (fetched 2026-07-14);
-- `@parity/product-sdk` 0.17.0;
+- `@parity/product-sdk` 0.19.1 (verified 2026-07-26);
+- `@polkadot-community-foundation/polkadot-app-deploy` 0.13.1;
 - explicit prototype / reference / unaudited status;
-- live preset environments: Paseo and Summit;
+- Product target: DevNet Asset Hub / People / Bulletin;
 - contracts package: `pallet-revive`, PolkaVM artifacts, and CDM manifests;
 - Statement Store: 512-byte statement payload, 1024-byte user total, default
   30-second TTL.
 
 | Item | Tracking | Status |
 | --- | --- | --- |
-| Product SDK baseline: pin SDK versions, document compatible Host surfaces, and add feature detection for Host local storage, signing, permissions, resource allocation, payments, and chain support. | #85, `polkadot-product-readiness-and-killer-dapp-roadmap.md` | Proposed |
+| Product SDK baseline: pin SDK versions, detect Host availability, connect an app-scoped account explicitly, and separate presence identity from EVM signing authority. | #85, `polkadot-product-readiness-and-killer-dapp-roadmap.md` | Delivered on Product adaptation branch |
 | Contract portability spike: compare Dotify's current Paseo Asset Hub EVM / viem / Hardhat flow with Product SDK contracts on `pallet-revive`, PolkaVM artifacts, and CDM manifests. | #85 | Proposed |
-| Playground deployment spike: determine whether Dotify's static build can use Playground/Bulletin/DotNS deploy flows without weakening current secret and publication boundaries. | #85 | Proposed |
+| Product deployment baseline: build a browser-safe multi-file bundle, publish through Bulletin/DotNS tooling, preserve backend key custody, and use a canonical public room URL. | #85 | Delivered on Product adaptation branch; live publication pending operator credentials |
 | Statement Store presence spike: use it for small, signed, ephemeral discovery/presence only. Do not move SDP/ICE, full chat history, media metadata, or link-only guest reactions there until signer, TTL, and size constraints are solved. | #89, `20-room-social-layer.md`, `21-room-collaborative-queue.md` | Proposed |
 | Humanity / Individuality research rewrite: prove the canonical live source, privacy-preserving proof shape, product-account/identity-account binding, and fallback UX before promoting Human free from research to build. | #12, `11-proof-of-personhood-integration-research.md` | Open |
 

docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md

@@ -1,15 +1,16 @@
 # Polkadot product readiness and killer dapp roadmap
 
-Status: active planning note, supersedes the stale draft from PR #91.
+Status: active execution note; the Product DevNet baseline is implemented on
+`feat/product-devnet-adaptation`.
 
-Last Product SDK verification: 2026-07-14 against
-`paritytech/product-sdk@2f359bba28ca72855207a0a519d4118b37b4438c`
-(`@parity/product-sdk` 0.17.0).
+Last Product SDK verification: 2026-07-26 against
+`@parity/product-sdk` 0.19.1 and
+`@polkadot-community-foundation/polkadot-app-deploy` 0.13.1.
 
 ## Verdict
 
-Dotify should align with the Polkadot product ecosystem, but it should not
-replace its standalone production path with Product SDK assumptions yet.
+Dotify should align with the Polkadot product ecosystem without replacing its
+standalone production path with Product SDK assumptions.
 
 The right product shape is dual-mode:
 
@@ -23,6 +24,19 @@ The right product shape is dual-mode:
   product failure state. It must not fall back to demo secrets, hidden signers,
   or bypassed access checks.
 
+The first adaptive slice is now implemented:
+
+- a separate Product DevNet build and `dotify-test01.dot` manifest;
+- explicit Host detection and app-scoped Product account connection;
+- Product identity for room presence without claiming EVM/EIP-191 authority;
+- canonical `.dev-dot.li` room links;
+- shared Fly API/signaling allowlists for Netlify and Product origins;
+- a pinned build/deploy workflow and operator rollback guide.
+
+Typed runtime ports are now extracted in the follow-up branch. Product-native
+contract writes, Product-signed key requests, Product personhood, and Product
+presence transport remain gated follow-up work.
+
 ## Product ecosystem evidence
 
 The current Parity product direction is coherent: Levity for publishing,
@@ -35,9 +49,8 @@ The SDK details matter for Dotify:
 
 - Product SDK and Playground are explicitly prototype / reference / unaudited
   code.
-- Product SDK preset chains are live for Paseo and Summit. Polkadot and Kusama
-  preset paths are gated because Bulletin / Individuality descriptors are not
-  live there.
+- Product DevNet exposes the Asset Hub, People, and Bulletin system-chain
+  topology used by the current Product tooling.
 - Product SDK contract helpers target `pallet-revive`, PolkaVM artifacts, and
   CDM manifests. Dotify currently uses Hardhat Solidity, generated EVM ABIs,
   viem, and Paseo Asset Hub EVM RPCs.
@@ -131,24 +144,37 @@ Goal: deepen rooms without breaking the room-guest doctrine.
 
 Goal: prove the Product host path with small spikes before committing the app.
 
-- Pin Product SDK versions and add a compatibility matrix.
-- Detect Host availability and supported chain/capability surfaces.
-- Prototype Product account connection, signing, identity prompt behavior, and
-  resource allocation.
+- Delivered: pin Product SDK/deploy versions and add a compatibility matrix.
+- Delivered: detect Host availability without blocking standalone first sound.
+- Delivered: connect the app-scoped Product account only on explicit action and
+  separate identity capability from EVM signing capability.
+- Delivered: publishable Bulletin/DotNS build and dual-origin Fly boundary.
+- Remaining: prototype host transaction signing and resource allocation.
 - Compare Dotify's Hardhat/EVM runtime with Product SDK PolkaVM/CDM contracts.
-- Prototype Playground deployment against Dotify's single-file build and secret
-  boundary.
 - Prototype Statement Store presence with strict payload, TTL, and signer
   limits.
 
 ### Phase 4 - Product integration
 
-Goal: ship Product mode as progressive enhancement.
-
-- Add Product-mode adapters behind explicit ports, leaving standalone adapters
-  intact.
-- Use Host signing and Product accounts only when the Host path is available.
-- Surface Host permission denial as actionable UI state.
+Goal: deepen the delivered Product mode one adapter at a time.
+
+- Delivered: keep standalone adapters intact and lazy-load Product host code.
+- Delivered: use the Product account as presence identity only when available.
+- Delivered: surface host absence and unsupported signer boundaries explicitly.
+- Delivered on the follow-up branch: extract typed runtime read/write ports and
+  move the current viem runtime implementation behind `RuntimeReadPort` /
+  `RuntimeWritePort`.
+- Delivered on the next follow-up branch: add an experimental CDM/PAPI adapter
+  behind those ports. It is not selected by default until Dotify has
+  CDM-installed Product runtime packages and host-signed transaction evidence.
+- Delivered on the next follow-up branch: add an API-side Product sr25519
+  signature scheme for key delivery and session sign-in. It binds the Product
+  account public key to the derived H160 requester before nonce consumption and
+  access checks.
+- Next: wire a generated CDM manifest/types into Product mode and run real host
+  transaction smoke tests.
+- Next: wire frontend Product-host key/session requests to the API signature
+  scheme and run real host smoke tests.
 - Keep backend key delivery authoritative unless a Product-host design proves a
   stronger key-custody boundary.
 - Keep `.dot`/Playground deployment separate from access enforcement.
@@ -219,8 +245,10 @@ Recommended Project 5 fields:
 - #36: closed after hosted signaling operation evidence.
 - #37: closed after #99 and manually checked deploy-host production env
   evidence.
-- #85: split into Product SDK baseline, contract portability, Playground deploy,
-  Statement Store presence, and integration adapter spikes.
+- #85: Product SDK baseline, Product DevNet deployment slice, and typed runtime
+  port extraction implemented; keep open for CDM/PAPI contract portability,
+  backend Product signatures, resource allocation, and bounded Statement Store
+  presence.
 - #86: implementation active on `codex/86-catalog-read-model`; keep In Progress
   until review and public performance evidence close the warm/cold budgets.
 - #87: keep for responsive cover/gateway pipeline.