Technical Architecture
How VideoVerify.Me is built
A conceptual overview of the recommended technical approach, plus the open questions that need to be resolved before moving into full product specification.
Technical stack overview
This is a conceptual-level overview, not a full engineering specification. The choices below reflect the privacy requirements first, then performance and cost.
| Component | Recommended Approach | Rationale |
|---|---|---|
| Video transport | WebRTC with forced TURN relay | Prevents IP address exposure between parties |
| TURN server | Self-hosted coTURN or managed TURN service (e.g., Twilio Network Traversal, Metered.ca) | Control over relay infrastructure is essential for privacy guarantees |
| Signaling server | WebSocket-based, Node.js or similar | Lightweight, real-time session negotiation |
| Session URL generation | Cryptographically random token (128-bit entropy, base62 encoded) | Opaque, unguessable, non-sequential |
| Session storage | Ephemeral, in-memory or short-TTL cache (e.g., Redis) | Sessions should not be written to durable storage |
| Host accounts | Standard email/password with bcrypt hashing | Minimal identity footprint |
| Geolocation scoring | Server-side IP intelligence lookup (e.g., MaxMind GeoIP2, ipinfo.io) | Accurate ISP and location data without client-side exposure |
| Screenshot deterrence | Canvas-based watermark overlay on video element | Visible deterrent with session traceability |
| Frontend | React SPA, no native app required | Browser-based, zero install for Guests |
Session URL design
The session URL should be structured to be opaque: a short, random-looking token with no embedded metadata that a curious Guest could decode. The token should be generated from at least 128 bits of cryptographic entropy and encoded in base62 (alphanumeric only, no special characters) for clean URLs.
This tells the recipient nothing except that they have been invited to a session. No host identity, no session metadata, no expiry time is encoded in the URL itself.
Open questions
These questions are not answered in this document and should be resolved before moving into full product specification or build planning.
What is the right daily session limit for the Free tier?
Three is the suggested starting point, but this should be calibrated against cost-per-session and conversion rate assumptions once real usage data is available.
What is the right maximum duration for a Free session?
Fifteen minutes is suggested, but user research may indicate that most verification calls are shorter (5 minutes) or that users want more time. This affects both UX and infrastructure cost.
Should the platform notify the Guest when a session expires before they join?
This would require collecting the Guest's contact information, which conflicts with the no-identity-for-Guests principle. The likely answer is no, and the Host is responsible for following up through the dating platform if needed.
How does the platform handle abuse and moderation?
Since no media is stored, moderation is limited to account-level action. A defined policy for handling reports of misuse (e.g., a Host using the platform for harassment) is needed before launch.
What are the legal requirements for the geolocation scoring feature?
The requirements vary by jurisdiction, particularly under GDPR in Europe and various US state privacy laws. Legal review is required before this feature ships.
What is the consent model for the Verified Snapshot feature?
The Snapshot feature requires retaining a brief recording. The consent flow must be carefully designed and reviewed by counsel. It must be explicit, opt-in, and clearly disclosed.
What should the Pro tier be named?
"Pro" is a placeholder. The name should reflect the safety and trust positioning of the product rather than a generic software tier label. Options to explore: SafePass, TrustPass, VerifiedPro.