1. Executive Summary
Enso is a privacy-first, proximity-based social discovery platform that connects people based on shared intents and physical proximity. The platform enables users to discover, signal, match, and chat with nearby individuals through time-limited "collision" sessions that expire after 24 hours.
The application is built on a modern, cloud-native architecture leveraging React Native for cross-platform mobile delivery and Supabase (hosted PostgreSQL) for backend services. Security is embedded at every layer: from row-level database security policies to encrypted communications, privacy-by-default user controls, and comprehensive content moderation.
Core Security Principles
🔒 Privacy by Default
Users are invisible until they actively choose to be discoverable. No passive tracking.
🛡️ Zero-Trust Data Model
Row-Level Security (RLS) enforces access control at the database layer — every query, every time.
⏱️ Ephemeral Connections
Chat sessions auto-expire in 24 hours, minimizing data retention surface area.
🔐 End-to-End Encryption
All data in transit secured via TLS 1.3. AES-256 at rest. PCI DSS via Stripe.
📦 Minimal Data Collection
Only data essential for core functionality is collected. No data sold to third parties.
👤 User Sovereignty
Users control visibility, data sharing, and can delete all data at any time. GDPR/CCPA compliant.
2. Scale Context: Why Security Architecture Matters Now
Enso is raising $1.5M pre-seed to scale from seed city to national rollout. The security architecture described in this document is designed not just for launch — but to support the growth trajectory investors and partners are backing.
This three-sided marketplace — users, creators, and venues — creates compounding security responsibilities. Each partner type introduces different data concerns:
| Stakeholder | Data Sensitivity | Security Requirement |
|---|---|---|
| Users (400K MAU Y3) | Location, intents, chat, payment | RLS isolation, ephemeral data, GDPR deletion |
| Venues (1,000+) | Foot traffic, analytics, bookings, revenue | Business data isolation, Stripe Connect, staff permissions |
| Creators (15,000) | Audience data, broadcast history, earnings | Follower privacy, content moderation, payout security |
Design philosophy: Every RLS policy, encryption standard, and retention rule in this document was built to serve not just 15,000 MAU at launch — but 400,000 MAU at scale, across 20+ cities, with thousands of venue and creator partners holding real business data on the platform.
3. Platform Architecture
3.1 Technology Stack
| Layer | Technology |
|---|---|
| Mobile Client | React Native (Expo SDK 54) — iOS & Android |
| Backend Platform | Supabase (PostgreSQL 15, GoTrue Auth, Realtime, Storage) |
| Database | PostgreSQL 15 with PostGIS extension for geospatial queries |
| Authentication | Supabase GoTrue (JWT-based) with OAuth providers |
| Real-time | Supabase Realtime (WebSocket) for live messaging |
| Push Notifications | Expo Push Notification Service + Supabase Edge Functions |
| File Storage | Supabase Storage with signed URL access control |
| Payments | Stripe + RevenueCat for subscription management |
| Edge Functions | Deno-based Supabase Edge Functions (3 deployed) |
| AI Services | Edge Function proxying to LLM provider (Cue AI) |
| Hosting Region | Supabase Cloud (AWS infrastructure, US region) |
3.2 Architecture Overview
| Component | Description |
|---|---|
| Mobile App | React Native client (53,454 LOC, 68 screens) handling UI, location services, and local state |
| Supabase API (PostgREST) | Auto-generated REST API with RLS enforcement on every query |
| Supabase Auth (GoTrue) | JWT token issuance, OAuth, email/password authentication |
| Supabase Realtime | WebSocket connections for live chat and presence (30-second refresh) |
| Supabase Storage | Secure file storage for profile photos and media |
| Edge Functions | Serverless compute for push notifications, AI chat, moderation |
| PostgreSQL + PostGIS | 65 tables, 56 RPCs, geospatial indexing for proximity queries |
3.3 Data Flow
All client-server communication follows this pattern:
- Client authenticates via Supabase Auth, receiving a signed JWT
- JWT is included in every API request as a Bearer token
- PostgREST validates the JWT and applies Row-Level Security policies
- Database queries execute with the authenticated user's context
- Results are filtered by RLS before being returned to the client
- Real-time subscriptions are authorized per-channel with RLS
At scale: This pattern handles 400K MAU because PostgREST and RLS are PostgreSQL-native — they scale horizontally with the database. No application-layer authorization code to audit or maintain.
4. Authentication & Authorization
4.1 Authentication Methods
| Method | Details |
|---|---|
| Email/Password | Bcrypt-hashed passwords, configurable password policy |
| OAuth 2.0 | Google, Apple Sign-In via Supabase GoTrue |
| JWT Tokens | Short-lived access tokens (1 hour) + refresh tokens |
| Session Management | Automatic token refresh; sessions revoked on password change |
4.2 Row-Level Security (RLS)
Every table in the database has RLS enabled. Policies ensure users can only access their own data or data explicitly shared with them. This is enforced at the PostgreSQL level, meaning even direct database access respects these boundaries.
| Table | Operation | Policy |
|---|---|---|
| profiles | SELECT | Users can read any public profile |
| profiles | UPDATE | Users can only update their own profile |
| collisions | SELECT | Only participants (user1_id or user2_id) can view |
| messages | SELECT/INSERT | Only collision participants can read or send messages |
| signals | INSERT | Authenticated users can send signals |
| signals | SELECT | Users can view signals they sent or received |
| collision_ratings | INSERT | Only collision participants can rate |
| booking_requests | SELECT | Only requester or venue owner can view |
| broadcasts | SELECT | Public broadcasts visible to all authenticated users |
| venue_profiles | UPDATE | Only venue owner can modify their profile |
4.3 Role-Based Access (Three Modes)
The platform supports multiple user modes with different permission levels — a critical security boundary as the platform scales from User-only to the full three-sided marketplace:
| Mode | Capabilities | Y3 Scale |
|---|---|---|
| User | Discover, signal, match, chat, rate collisions | 400K MAU |
| Creator | All user capabilities + broadcasts, follower management, booking requests | 15,000 active |
| Venue | All user capabilities + custom interests, event hosting, booking management, venue dashboard | 1,000+ partners |
| Event Host | Event creation, attendee management, RSVP tracking, QR check-ins | Cross-mode |
Mode switching is centralized. Enso uses a React Context-based ModeContext system that manages state transitions between User, Creator, and Venue modes. Mode changes are validated server-side — a user cannot access venue analytics or creator broadcasts without the appropriate mode permissions in the database.
5. Data Protection & Privacy
5.1 Data Classification
| Category | Examples | Protection Level |
|---|---|---|
| PII — High | Email, phone, exact GPS coordinates | Encrypted at rest, RLS restricted, never shared |
| PII — Standard | Name, age, profile photo | RLS controlled, user-visible in discovery |
| Behavioral | Intents, interests, signal history | RLS controlled, anonymized in analytics |
| Transactional | Bookings, ratings, payments | RLS controlled, encrypted payment tokens |
| Content | Chat messages, broadcast content | RLS restricted to participants, auto-expires |
| Partner Data | Venue foot traffic, creator audience metrics | Owner-only access, anonymized aggregates for benchmarks |
| System | Device tokens, session logs | Internal only, no user exposure |
5.2 Encryption
| Layer | Standard |
|---|---|
| Data in Transit | TLS 1.3 for all API, WebSocket, and storage communications |
| Data at Rest | AES-256 encryption on Supabase-managed PostgreSQL (AWS) |
| Authentication Tokens | JWT signed with HS256; refresh tokens stored securely |
| Password Storage | Bcrypt with configurable rounds (default 10) |
| Payment Data | PCI DSS compliant via Stripe — no card data stored on platform |
| File Storage | Signed URLs with expiration; no public bucket access |
5.3 Location Data Handling
Location data is central to the discovery feature and is handled with particular care:
- Location is only collected when user explicitly activates a discovery session
- Coordinates are stored with intentional precision reduction for privacy
- Location data is ephemeral — not persisted beyond active session lifetime
- Users can revoke location permissions at any time via device settings
- Geospatial queries use PostGIS with configurable radius limits
- Venue check-in verification uses proximity validation, not continuous tracking
Why this matters for partners: Venues see anonymized foot traffic data and collision heatmaps — never individual user locations. Creator audience metrics are aggregated. This privacy-by-design approach lets Enso offer venue analytics ($73B event ticketing market) and creator insights ($205B creator economy) without exposing user PII to business partners.
5.4 Data Retention & Deletion
| Data Type | Retention Policy |
|---|---|
| Chat Messages | Auto-deleted when collision expires (24 hours default, 7 days for bookings) |
| Location Data | Cleared when discovery session ends |
| Signal History | Retained for match history; user-deletable |
| Profile Data | Retained until account deletion |
| Payment Records | Retained per legal requirements (Stripe manages) |
| Push Tokens | Rotated on app update; cleared on logout |
| Account Deletion | Full data purge within 30 days of request, per GDPR/CCPA |
Retention benchmark: Dating apps retain chat data indefinitely. 69% of dating app downloads are deleted within one month (AppsFlyer 2025). Enso's auto-expiring ephemeral model means less data liability — when users leave, their data leaves too.
6. Infrastructure Security
6.1 Supabase Platform Security
Enso's backend is hosted on Supabase Cloud, which provides enterprise-grade infrastructure security:
- SOC 2 Type II certified infrastructure
- Hosted on AWS with multi-AZ redundancy
- Automated daily backups with point-in-time recovery (PITR)
- Network isolation with VPC and security groups
- DDoS protection via AWS Shield and Cloudflare
- Regular security patching and vulnerability scanning
- 99.9% SLA uptime guarantee
6.2 API Security
| Control | Implementation |
|---|---|
| Rate Limiting | Supabase built-in rate limiting per IP and per user |
| Request Validation | PostgREST validates all query parameters against schema |
| CORS Policy | Restricted to application domains only |
| API Keys | Separate anon (public) and service_role (server-only) keys |
| Input Sanitization | Parameterized queries prevent SQL injection |
| Response Filtering | RLS ensures no unauthorized data leakage in responses |
6.3 Edge Functions Security
Serverless Edge Functions handle sensitive operations like push notifications, AI processing, and moderation:
- Deno runtime with sandboxed execution environment
- Environment variables for secrets (never hardcoded)
- Service role keys restricted to Edge Function environment only
- Request validation and authentication checks on every invocation
- No direct database access from client — Edge Functions mediate sensitive operations
7. Application Security
7.1 Client-Side Security
| Measure | Details |
|---|---|
| Secure Storage | Expo SecureStore for tokens and sensitive data |
| Certificate Pinning | Planned for production builds |
| Code Obfuscation | Metro bundler minification; Hermes bytecode compilation |
| Deep Link Validation | URL scheme validation before navigation |
| Biometric Auth | Planned integration for sensitive actions |
7.2 Content Moderation & Safety
- Photo moderation service for profile image screening
- User reporting system with structured report categories
- Block/mute functionality with immediate effect
- AI-assisted conversation safety (Cue AI) for chat interactions
- Event content review for venue and creator-generated content
- Automated flag system for suspicious activity patterns
- 764-line moderation system for venue interaction management
7.3 Payment Security
All payment processing is handled by PCI DSS Level 1 certified providers:
- Stripe handles all payment card processing — no card data touches Enso servers
- RevenueCat manages App Store and Google Play subscription billing
- Payment tokens are provider-managed and never stored in application database
- Webhook signatures validated for all payment event notifications
- Subscription state synchronized with server-side verification
Pricing context: Enso Premium at $9.99/mo sits below Tinder Gold ($14.99), Bumble Premium ($29.99), and Hinge+ (up to $45/mo). Stripe + RevenueCat handle all payment complexity — Enso never touches card data. At 10% conversion on 400K MAU, this architecture must securely process ~40,000 recurring subscriptions.
8. User Privacy Controls
Enso is designed with privacy-first principles. Users have granular control over their data and visibility:
| Control | Description |
|---|---|
| Invisible by Default | Users are not discoverable until they activate a session with a specific intent |
| Intent-Based Visibility | Users only appear to others with complementary intents |
| Discovery Radius | User-configurable proximity range for discovery |
| Profile Visibility | Control which profile fields are visible during discovery |
| Block & Report | Immediate block with option to report; blocked users cannot discover or contact |
| Chat Expiration | Collisions auto-expire, automatically removing chat history |
| Data Export | Users can request a full export of their personal data |
| Account Deletion | Complete data removal with confirmation flow |
| Location Control | Discovery requires active opt-in; location not tracked passively |
| Notification Preferences | Granular control over push notification types |
9. Database Schema & Security Design
9.1 Core Tables
The database comprises 65 tables organized around the core collision lifecycle with strict relational integrity. Below are the security-critical tables:
| Table | Purpose | RLS Policy |
|---|---|---|
| profiles | User identity and preferences | Own profile: full access; others: read-only public fields |
| collisions | Match records between users | Participants only |
| messages | Chat messages within collisions | Collision participants only |
| signals | Interest signals between users | Sender and receiver only |
| collision_ratings | Post-collision feedback | Participants only; one per user per collision |
| events | Event listings | Public read; host: full CRUD |
| event_rsvps | Event attendance tracking | Own RSVPs: full; event host: read |
| broadcasts | Creator/venue announcements | Public read; creator: full CRUD |
| booking_requests | Venue booking management | Requester and venue owner only |
| venue_profiles | Venue-specific metadata | Owner: full CRUD; others: read-only |
| creator_profiles | Creator-specific metadata | Owner: full CRUD; others: read-only |
| venue_custom_interests | Venue-created discoverable intents | Venue owner: full CRUD; users: read |
9.2 Geospatial Security
PostGIS-powered location queries enforce privacy boundaries:
- Discovery queries use ST_DWithin with user-configurable maximum radius
- Exact coordinates are never exposed to other users
- Distance calculations return approximate ranges, not precise distances
- Venue check-ins validate proximity without storing user location history
10. Partner Trust: Venue & Creator Security
As Enso scales from 25 venue partners to 1,000+ and from 100 creators to 15,000, partner data isolation becomes a critical competitive moat. Venues and creators choose Enso because they trust the platform with their business data.
10.1 Venue Data Isolation
Each venue partner operates within a strict security perimeter:
- Dashboard access: Venue analytics (foot traffic, collision heatmaps, benchmarking) are RLS-restricted to the venue owner's account
- Event management: 13-screen event management suite with RLS on attendee lists, RSVP data, and check-in records
- Staff permissions: Moderation system (764 lines) enables venue staff management without exposing owner-level data
- Financial isolation: Stripe Connect provides separate payment processing per venue — Enso never commingles venue funds
- Custom interests: A/B testing data for venue-created intents is isolated to the venue owner
10.2 Creator Data Protection
- Audience privacy: Creators see follower counts and engagement metrics — never individual follower PII or locations
- Broadcast analytics: Read rates, response rates, and reach metrics are creator-visible; underlying user data is anonymized
- Booking security: Booking requests between creators and venues are visible only to the two parties involved
- Content ownership: Creator broadcast content is controlled by the creator with full CRUD permissions
10.3 The Partner Flywheel & Trust
Enso's growth model depends on a flywheel: creators broadcast → followers arrive at venues → users collide → venue books creator again. This flywheel only works if all three sides trust the platform with their data. Security isn't overhead — it's the product.
Scaling benchmark: At Year 3 targets (1,000 venues × 65 avg. per city across 15+ cities), the platform will manage thousands of concurrent venue dashboards, creator analytics panels, and event management workflows — each isolated by RLS, each with its own payment processing, each auditable.
11. Scaling Security: Growth Roadmap
Security architecture evolves with each growth phase:
| Phase | Scale | Security Milestones |
|---|---|---|
| Phase 1: Seed City | 50K users, 25 venues, 100 creators | RLS policies hardened. Pen testing pre-launch. SOC 2 infrastructure (via Supabase). Certificate pinning deployed. Photo moderation active. |
| Phase 2: Expand | 250K users, 200 venues, 2K creators, 5 cities | Rate limiting tuned for multi-city load. Venue staff permission tiers. Creator content review automation. Biometric auth for sensitive actions. Incident response exercised. |
| Phase 3: Scale | 1M+ users, 1,000 venues, 15K creators, 20+ cities | Enterprise venue deals → dedicated security review. API partnerships → OAuth scope restrictions. Data products → differential privacy for anonymized analytics. SOC 2 Type II audit (application-level). Bug bounty program launched. |
| Phase 4: Platform | International, developer SDK, white-label | GDPR data residency per region. Developer SDK sandboxing. White-label venue tools with tenant isolation. International compliance (LGPD, PIPA). PCI DSS Level 2 direct certification. |
Investment context: Of the $1.5M pre-seed raise, 40% ($600K) is allocated to Product & Engineering. Security infrastructure — including pen testing, SOC 2 preparation, and scaling RLS policies — is a first-order product investment, not a compliance afterthought.
12. Compliance & Regulatory
12.1 Regulatory Framework
| Regulation | Status |
|---|---|
| GDPR (EU) | Compliant — Data minimization, right to erasure, data portability |
| CCPA (California) | Compliant — Opt-out rights, data access requests, deletion rights |
| COPPA (Children) | Compliant — 18+ age requirement enforced at registration |
| PCI DSS | Compliant via Stripe/RevenueCat (no direct card handling) |
| SOC 2 | Infrastructure compliant via Supabase (SOC 2 Type II certified) |
| App Store Guidelines | Compliant with Apple and Google content and privacy policies |
12.2 Data Processing
- Data processing agreements (DPAs) in place with Supabase, Stripe, and RevenueCat
- Data residency: Primary database hosted in US region (AWS)
- No data sold to third parties — data used solely for platform functionality
- Minimal third-party data sharing: only payment processors and push notification services
- Privacy policy and terms of service clearly disclose all data practices
12.3 Incident Response
- Security incident classification and escalation procedures documented
- 72-hour breach notification commitment (GDPR requirement)
- User notification process for data breaches affecting personal data
- Post-incident review and remediation tracking
- Regular security assessment and penetration testing schedule
13. Third-Party Service Dependencies
| Service | Purpose | Security Posture |
|---|---|---|
| Supabase | Backend platform (DB, Auth, Storage, Realtime) | SOC 2 Type II, GDPR compliant, AWS-hosted |
| Stripe | Payment processing | PCI DSS Level 1, SOC 2 Type II |
| RevenueCat | Subscription management | SOC 2 Type II, GDPR compliant |
| Expo | Mobile build and push notifications | SOC 2, secure build infrastructure |
| Apple/Google | App distribution and in-app purchases | Platform-native security |
| Anthropic (Cue AI) | AI-powered chat assistance | Enterprise security, no data retention |
14. Secure Development Practices
14.1 Development Lifecycle
- Version control via Git with branch protection rules
- Environment separation: Development, Staging, and Production
- Secrets management via environment variables (never committed to source)
- Dependency vulnerability scanning with npm audit
- Code review process for all production changes
- EAS Build pipeline for reproducible, signed application builds
14.2 Dependency Management
- Regular npm audit for known vulnerabilities in dependencies
- Minimal dependency philosophy — prefer platform-native solutions
- Lock files (package-lock.json) committed for reproducible builds
- No known critical vulnerabilities in production dependencies
Codebase metrics: 53,454 lines of production code across 182 files. 68 screens, 24 services, 56 Supabase RPCs, 65 database tables, 3 Edge Functions. Every service and RPC enforces authentication. Every table has RLS enabled.
15. Security Contact & Disclosure
| Channel | Contact |
|---|---|
| Security Email | [email protected] |
| General Support | [email protected] |
| Responsible Disclosure | Via [email protected] with PGP encryption available |
| Data Protection Officer |