MirrorKey

Personalization without surrendering your face

MirrorKey is a consent-native firewall for appearance-powered commerce. It lets a shopper authorize one narrow YouCam computation while keeping the private visual out of the retailer or shopping agent's ordinary data flow.

The problem

Virtual try-on usually asks shoppers to trade privacy for utility. A store wants to answer a narrow question—"How would this jacket look?"—but the common implementation starts by collecting a reusable body or face image. Across stores and agents, those captures, provider identifiers, detailed appearance attributes, and generated results can multiply.

The retailer rarely needs that much data. It may only need to know that an approved preview completed.

The solution

MirrorKey turns appearance personalization into a permissioned capability:

A merchant requests one narrow computation for a specific SKU. The shopper sees a canonical consent manifest binding requester, purpose, garment digest, processor, expiration, output, withheld fields, and the current provider-unit quote. The shopper unlocks an AES-GCM encrypted JPEG VTO Key in the browser. In live mode, the browser uploads those approved pixels to one exact disclosed YouCam upload origin; provider file and task identifiers remain inside the control plane. YouCam AI Clothes v4 performs the appearance preview. The private render is delivered only to the shopper. The retailer receives the minimum approved disclosure: {"tryOnCompleted": true}. Cleanup records distinguish confirmed task deletion, unverified absence, pending cleanup, and failure without overstating erasure.

Overbroad RAW_SOURCE requests fail before provider work or unit spend.

Why YouCam is central

MirrorKey uses YouCam as the private appearance-compute engine rather than treating it as a decorative API call. The repository includes adapters and contracts for:

AI Clothes v4 for the core Apparel VTO flow Skin Analysis v2.1 for a coarse, consent-scoped condition-band contract Facial Color Tones as an extensible minimum-disclosure appearance capability File upload intents, unit-cost quotes, asynchronous task polling/webhooks, result capture, and task-deletion evidence

The public judge experience intentionally uses clearly labeled synthetic fixtures and states that it makes zero YouCam calls. The credentialed adapter is fail-closed: live mode cannot be enabled without the provider credentials, exact upload origin, durable workers, encryption keys, cost controls, and readiness gates. That boundary is visible rather than hidden.

Technical implementation

MirrorKey is a TypeScript monorepo:

Next.js/React consumer experience on Vercel Hono control plane on Fly.io Encrypted SQLite/WAL durable job state AES-256-GCM field encryption and browser vault encryption Ed25519 signed cleanup evidence Strict Zod capability contracts Durable execution and cleanup workers Action-bound HMAC continuations for prepare, authorize, execute, recovery, private viewer, and cleanup Exact-origin browser upload policy, bounded streaming I/O, idempotent replay handling, unit budgets, and fail-closed readiness

The API test suite covers provider-create ambiguity, restarts, webhook replay, quote drift, recovery, cleanup outcomes, source/garment digest binding, privacy disclosures, migrations, and adversarial payloads.

Consumer and retail value

For shoppers, MirrorKey provides understandable consent, reusable encrypted appearance data, private previews, revocation, and data receipts.

For retailers and commerce agents, it provides personalization without custody of reusable body imagery, a smaller breach/compliance surface, inspectable audit evidence, and a stable capability contract that can work across merchants.

The design is deliberately provider-compatible and cross-store: merchants bring the catalog request to the shopper's protected appearance capability instead of asking the shopper to surrender a new copy of their body image everywhere.

Screenshots

Built with Codex

Codex was used as an engineering collaborator for market research, API contract analysis, threat modeling, implementation, adversarial tests, security review, visual QA, release hardening, deployment, and submission preparation. The final project keeps the implementation and the evidence honest about fixture, mock, and credentialed-live states.

Screenshot gallery

Consent manifest: https://github.com/aryarahimi1/mirrorkey/blob/main/submission/screenshots/02-consent-manifest.png

Private compute ledger: https://github.com/aryarahimi1/mirrorkey/blob/main/submission/screenshots/03-private-compute-ledger.png

Private result and minimum disclosure: https://github.com/aryarahimi1/mirrorkey/blob/main/submission/screenshots/04-private-result-minimum-disclosure.png

Trust architecture: https://github.com/aryarahimi1/mirrorkey/blob/main/submission/screenshots/06-trust-architecture.png