Architecture: JWT vs TOTP — Deep Dive

Event Horizon implements a hybrid ticketing model: JWT for free events and TOTP for paid events. This page explains the rationale, the data model, and the serverless flow used in production.

When to use JWT (Free events)

• JWT is used for free events to allow instant, offline-capable validation.
• Tickets are issued with a static signature (RS256) signed by the server. Clients can rotate a time window locally to produce rotating QR payloads that are screenshot-resistant.

When to use TOTP (Paid events)

• Paid events require stronger fraud protection. The server generates a TOTP secret, encrypts it with the secrets store, and only validates TOTP tokens server-side.
• This prevents ticket cloning and enables revocation and server-side auditing.

Example ticket JSON

{
  "ticketId": "8821",
  "eventId": "event_123",
  "attendeeName": "Jane Doe",
  "attendeeEmail": "jane@example.com",
  "tierName": "General Admission",
  "price": 0,
  "purchaseDate": 1672531200,
  "signature": "base64-rsa-signature",
  "format": "JWT",
  "timeWindow": 123456
}

Serverless minting flow

1. User purchases or creates a ticket in the client.
2. Firestore onCreate trigger fires for events/{id}/tickets.
3. Cloud Function secure_mint_ticket() executes:
   • For free events: sign payload using KMS (RS256) and persist ticket with signature.
   • For paid events: generate TOTP secret, encrypt it using Secret Manager / Vault, store a reference in Firestore, and mark ticket as TOTP format.
4. Clients read the ticket and render either the JWT or TOTP UI.

AI & Semantic Search

The platform uses an AI stack (Genkit + Google AI / Gemini) to power semantic search for the Discover experience. Text embeddings (textEmbedding004) are computed and stored as vector fields to support relevance-based retrieval.