System context
The consumer Swapnice app (Firebase, wallet, NFC) is a different system. Partner traffic does not go there.End-to-end consumer path
The sequence below is the path a technical review should walk: user action → consent → event → archive → profile → partner product.1. Consumer interaction
A user does something in the partner product: views a collection, checks out, labels a fandom, or walks a stadium flow. The SDK observes only events you registered. Nothing is sent until a consent receipt exists for that purpose.2. Connect and consent
Connection sessions expire. Consent can later be revoked in part or in full. After revoke, ingest and purpose-scoped reads fail closed.3. Event acceptance
Guarantees partners can rely on:- FIFO per app + customer. Events for one customer go through one Durable Object.
- Idempotent writes. Retries do not duplicate durable effects.
- Consent at ingest. No receipt, no accept.
- Fast ACK. Partners are not blocked on archive or profile recompute.
4. Profile resolution
V1 resolves profiles at read time from archived D1 events. There is no separate profile-recompute Durable Object yet. The same gate applies to/claims and /intents.
5. Partner product output
The handoff is:- Swapnice returns permissioned profiles and intents for connected, consented users.
- The partner uses those reads inside its own product.
- Revoked purposes fail closed on ingest and purpose-scoped reads.
Split-worker map
Production routes through a gateway. Local development can run a single worker.Persistence
Security expectations
- OAuth 2.1 authorization code + PKCE (
S256) - Short-lived access tokens, hashed secrets and tokens at rest
- Exact redirect URI match
- Scoped tokens (
events:write,profile:read, …) - Revocable consent, purpose-checked ingest and reads
- Idempotency keys on mutating routes
- Correlation / request ids on errors
- No leakage of wallet, payment, or private identity fields