Lantern

Appearance

TODO List - Lantern App Development ​

Note on Grouping:

  • Fire Icon & Lantern Hub = UI component (the fire icon button and modal panel) - largely COMPLETED
  • Core Features: Lanterns, Waves & Connections = Backend integration and cross-device sync for the actual user-facing functionality

Dashboard Implementation ​

  • [X] Create initial Dashboard component from design mockup
  • [X] Add Dashboard to App.jsx routing
  • [X] Make Dashboard the default main view
  • [X] Create Dashboard.stories.jsx for Storybook
  • [X] Extract individual components (Button, Card, Badge, etc) to Storybook
  • [X] Add color palette to Storybook
  • [X] Add icons from lucide-react to Storybook
  • [X] Wire offers/ads to real API with hero + per-venue placements and expiration handling
  • [X] Add geolocation-aware fallback for hero offer selection when exact venue match is missing

Location ​

  • [ ] Lookup open-source geofencing considerations

Frens System (Privacy-First Reconnection) ​

Frontend Complete ✅ | Backend Pending ⏳

  • [X] Create comprehensive system documentation (FRENS_SYSTEM.md)
  • [X] Create quick reference guide (FRENS_QUICK_REF.md)
  • [X] Build SaveConnectionPrompt component
  • [X] Build FrensList screen with filters and search
  • [X] Build FrenProfile screen with venue management
  • [X] Build ManageVenuesModal component
  • [X] Create Storybook stories for all components
  • [X] Add routing (#/frens, #/frens/:id)
  • [ ] Firebase Backend Integration
    • [ ] Create Firestore connections collection schema
    • [ ] Implement connection creation (save fren)
    • [ ] Implement mutual detection (Cloud Function)
    • [ ] Add real-time listeners for lit lanterns
    • [ ] Build venue broadcasting queries
    • [ ] Implement connection removal
    • [ ] Add venue management CRUD
  • [ ] Real-Time Features
    • [ ] Live updates when frens light lanterns
    • [ ] Priority wave queue for mutual frens
    • [ ] Venue expansion prompts (when both present at new venue)
    • [ ] Mutual save notification system
  • [ ] Beacon Invites System
    • [ ] "I'll be at X venue on Y date" invite creation
    • [ ] One-way coordination (no back-and-forth chat)
    • [ ] Calendar integration
    • [ ] Reminder notifications
  • [ ] Analytics & Refinement
    • [ ] Track save rates (wave acceptance → save conversion)
    • [ ] Monitor venue expansion patterns
    • [ ] A/B test messaging variants
    • [ ] User feedback integration
    • [ ] Performance optimization

See: docs/features/frens/ for complete documentation

Chats ​

  • [ ] Discern what is "Active Chats"
  • [ ] Add the "New message from Venue and assigned name"

Code Quality & Testing (Audit Items) ​

  • [X] Add ESLint configuration (.eslintrc.json)
  • [X] Add Prettier configuration (.prettierrc.json)
  • [X] Add EditorConfig (.editorconfig)
  • [X] Add lint/format scripts to package.json
  • [X] Add VIM swap files to .gitignore (*.swp, *.swo, *.swn)
  • [X] Remove console.log statements from production code (wrap in isDevelopment check)
  • [X] Fix encryption module import (use single import, not mixed static/dynamic)
  • [X] Enable coverage reporting in vitest.config.js
  • [ ] Increase test coverage to 70%+ for critical paths (auth, data persistence, encryption)
    • [ ] Test auth flows (signup, login, passphrase)
    • [ ] Test encryption/decryption operations
    • [ ] Test Firestore CRUD operations
    • [ ] Test Chat message handling
  • [ ] Add Firebase mock setup for unit tests
  • [ ] Implement code-splitting for bundle size optimization (main bundle 760kB → <500kB target)
    • [ ] Use dynamic imports for route-based code splitting
    • [ ] Consider splitting Firebase SDK imports
    • [ ] Configure build.rollupOptions.output.manualChunks in Vite
  • [ ] Add a11y (accessibility) testing with axe-core in Vitest
  • [ ] Add CI/CD workflows (.github/workflows)
    • [ ] PR validation workflow (lint, tests, SAST, dependency scanning)
    • [ ] Build and publish workflow
  • [ ] Add Docker configuration (Dockerfile, docker-compose.yml)
    • [ ] Development environment
    • [ ] Production build

UI/UX ​

  • [ ] Need perhaps a loading page when a window refreshes instead of just showing the "signup/login" screen.
  • [ ] Need better page persistence when a window is refreshed.

Multi-Tab IndexedDB Persistence ​

Context: Firestore's IndexedDB persistence only works in one tab at a time. When multiple tabs are open, persistence fails silently, causing login state to not survive refreshes on secondary tabs.

Potential Solutions (pick one or combine):

  • [ ] Option 1: Enable Firebase multi-tab sync
    • [ ] Use synchronizeTabs: true in enableIndexedDbPersistence() (experimental feature)
    • [ ] Test cross-tab state synchronization
    • [ ] Document any performance implications
  • [ ] Option 2: UI warning for multi-tab scenario
    • [ ] Detect when IndexedDB persistence fails (already have catch block)
    • [ ] Use BroadcastChannel API to detect other tabs
    • [ ] Show banner/toast: "Multiple tabs detected - close others for best experience"
    • [ ] Add dismissible warning with "Don't show again" option
  • [ ] Option 3: Visual persistence status indicator
    • [ ] Add small icon in header/footer showing persistence state
    • [ ] Green = persistence active, Yellow = degraded (multi-tab), Red = failed
    • [ ] Tooltip explaining what it means
  • [ ] Option 4: Auto-focus existing tab
    • [ ] On new tab open, detect existing tab via BroadcastChannel
    • [ ] Show message: "Lantern is already open in another tab"
    • [ ] Provide button to focus existing tab (using window.focus() + BroadcastChannel)
    • [ ] Prevent multi-tab entirely (aggressive but clear UX)
  • [ ] Option 5: Tab coordination system
    • [ ] Designate first tab as "primary" using localStorage timestamp
    • [ ] Secondary tabs show read-only mode or redirect to primary
    • [ ] Use BroadcastChannel to communicate between tabs
    • [ ] When primary closes, promote next tab to primary

Recommended Approach: Start with Option 1 (synchronizeTabs) + Option 2 (UI warning) for graceful fallback.

User Profile & Privacy ​

  • [X] Create privacy-first profile system (no photos, no age display)
  • [X] Implement Lantern Name generator (pseudo-username system)
  • [X] Build UserProfile component (interests + mood only)
  • [X] Build ProfileSettings page with privacy controls
  • [X] Create client-side encryption utilities for birth date
  • [X] Document venue age rules and verification schema
  • [X] Add profile stories to Storybook
  • [ ] Wire UserProfile to Firebase: save interests, mood, lantern name to Firestore
  • [ ] Implement encrypted birth date persistence (client-side encryption before transmission)
  • [ ] Create Firestore data model for profiles with schema validation
  • [ ] Add Firestore security rules for encrypted profile data (deny direct plaintext reads)
  • [ ] Implement Firebase Auth + Firestore triggers to auto-create profile documents on signup
  • [ ] Test profile creation flow: signup → auto-generate profile document → sync to device storage
  • [ ] Verify encrypted data storage: birth date should be stored as encrypted blob in Firestore
  • [ ] Add profile sync across multiple devices using Firestore real-time listeners
  • [ ] Test cross-device sync: update profile on device 1 → appears on device 2 within seconds
  • [ ] Implement server-side age verification for venue access
  • [ ] Build onboarding flow with age verification (18+ gate)
  • [ ] Implement backup codes for account recovery (printed at signup)
  • [ ] Implement data retention policy (48hr check-ins, 30-day deletion)
  • [ ] Add account deletion flow with encrypted data cleanup
  • [ ] Potentially allow for biometric login?

Business ​

  • [X] Keep costs as transparent as possible
  • [X] Add in risk/reward considerations
  • [X] Add in revenue/cost breakdown
  • [ ] Define merchant tiers and commission structure
  • [ ] Create revenue model documentation and potential projections
  • [ ] Plan marketing channels and partnerships

Trademark & IP Strategy ​

See docs/business/IP_STRATEGY.md for full details.

  • [ ] URGENT: Trademark search — Search WIPO/USPTO for "Lantern" availability in Classes 35, 42, 43
    • [ ] Check US (USPTO), EU (EUIPO), Canada
    • [ ] Timeline: 1–2 weeks; Cost: ~$200–400
    • [ ] If available, proceed to filing; if not, identify fallback brand names
  • [ ] Provisional patent application (optional) — File for geofence + fraud detection + redemption system
    • [ ] Establishes priority date and "patent pending" status for 12 months
    • [ ] Cost: ~$300–500; Timeline: 1 day to file
    • [ ] Decide post-pilot whether to convert to full utility patent
  • [ ] US Trademark filing — Once availability confirmed (if available)
    • [ ] Cost: ~$300–500; Timeline: 6–12 months to grant
    • [ ] Can use "™" immediately; use "®" only after grant
  • [ ] Trade secret documentation — List proprietary algorithms, data insights, business metrics
    • [ ] Implement confidentiality agreements (NDAs) for all employees/contractors
    • [ ] Set up access controls for sensitive code/data
    • [ ] Brief team on what constitutes trade secrets
  • [ ] Review this GPT link to integrate next steps into documentation: https://chatgpt.com/share/695b2974-003c-8005-8b3f-8bd121e4e7fc
  • [ ] Create terms of service (ToS) with IP ownership and brand usage restrictions
  • [ ] Create privacy policy aligned with zero-knowledge encryption
  • [ ] Ensure GDPR compliance for encrypted data
  • [ ] Establish data deletion procedures
  • [ ] Create legal documentation for venue partnerships
  • [ ] Document brand guidelines (official "Lantern App" usage for partners)

Merchant Features ​

  • [ ] Add in merchant analytics
    • [ ] How many "waves" happened in the establishment
    • [ ] How many offers were redeemed
  • [ ] Could we potentially integrate with POS systems?
  • [ ] Create better merchant dashboard
  • [ ] Connect merchant offer creation to backend endpoint and surface status/errors in UI
  • [ ] Implement offer scheduling and auto-expiration
  • [ ] Add merchant performance metrics
  • [ ] Create bulk offer upload functionality
  • [ ] Add in elegant way for a merchant to register and be given access to the "merchant center".
  • [ ] How would the merchant center run? Would it just be a page path and locked behind a login?

Storybook ​

  • [X] Ensure that the storybook log is configured appropriately
  • [X] Add HeroOfferCard story
  • [X] Add OfferPill story
  • [X] Add inline venue card story showcasing offer pill state
  • [X] Document key differences between "screens" vs "components"
  • [X] Add story for profile onboarding flow
  • [X] Add story for lantern lighting interaction
  • [X] Add story for wave notification UI
  • [X] Add PlacesScreen story (wraps HomeView)
  • [X] Add VenueDetailScreen story (wraps VenueView)
  • [X] Add ActiveLanternScreen story (wraps ActiveLanternView)
  • [X] Add LanternSuccessScreen story (success state wrapper)

Logging & Monitoring ​

  • [ ] Add better logging to overall system checks
  • [ ] Implement debug mode for Firebase calls
  • [ ] Add encryption/decryption operation logging (dev-only)
  • [ ] Set up error tracking (e.g., Sentry)
  • [ ] Add analytics for feature usage
  • [ ] Create dashboard for app health metrics
  • [ ] Implement real-time alerting for critical errors
  • [ ] Add performance profiling
  • [ ] Create user behavior analytics

Core Features: Lanterns, Waves & Connections ​

Phase 1: Location spoofing, cross-device testing, basic functionality verificationPhase 2: Wave interaction rules and auto-shutoff logicPhase 3: Advanced features like history, analytics, and encrypted notifications

  • [ ] Test basic lantern lighting at spoofed venue from multiple devices
  • [ ] Verify wave notifications sync across devices
  • [ ] Test lantern auto-extinguish when user leaves venue
  • [ ] Turn off manually
  • [ ] Turn off once you actually meet
  • [ ] Turn off when you leave the location or after 2 hrs
  • [ ] Limit waves (define rate limits and rules)
  • [ ] Add wave history and analytics
  • [ ] Implement wave acceptance/rejection logic
  • [ ] Create wave notifications with encrypted sender info
  • [ ] Allow user to either set location, allow for location track ( when app is opened ), or only allow to search for venues by entering their preferred location
  • [ ] Can only light lantern at one venue at a time
  • [ ] Ability to wave at someone without needing to light one's lantern ( but would still need to be in the venue )

Fire Icon & Lantern Hub ​

  • [X] Fire icon primary action: Quick access to light lantern at current/nearby venue (must be venue-specific for safety & merchant model)
  • [X] Fire icon visual state: indicate whether user has active lantern (glowing/animated when lit)
  • [X] Design "Lantern Hub" panel showing: active lantern details, recent waves, scheduled lights, quick extinguish
  • [X] Fire icon when lit: Show active lantern status, recent waves, connection activity panel
  • [X] Add light interaction history in hub
  • [X] Schedule a light feature: Allow users to pre-schedule lantern lighting (e.g., "Going to yoga at 6pm tomorrow")
  • [X] Consider long-press or secondary interactions for additional quick actions
  • [ ] Add countdown timer for scheduled lights

Security & Privacy ​

  • [X] Document privacy-first architecture (no photos, no age display, encrypted birth dates)
  • [X] Create client-side encryption utilities (Web Crypto API)
  • [X] Document venue age verification system
  • [X] Implement zero-knowledge encryption (passphrase-based, client-side only)
  • [X] Build SignupFlow with zero-knowledge architecture
  • [X] Document zero-knowledge encryption architecture and legal implications
  • [X] Position encryption as legal safe harbor ("we literally can't decrypt user profiles")
  • [X] Create comprehensive security architecture documentation (SECURITY_ARCHITECTURE.md)
  • [X] Build user-friendly security guide (USER_SECURITY_GUIDE.md)
  • [X] Establish community vulnerability disclosure program (VULNERABILITY_DISCLOSURE.md)
  • [X] Document hybrid security model (zero-knowledge + device-local + public data)
  • [X] Create visual guides to encryption (ZERO_KNOWLEDGE_VISUAL_GUIDE.md)
  • [X] Add security architecture comments to Chat.jsx

Phase 1: Dev/testing setup (location spoofing, encryption verification, Firestore rules) Phase 2: Auth & account security (backup codes, age verification, safety features) Phase 3: Advanced encryption (zero-knowledge proofs, Signal Protocol, external audits)

  • [X] Add location spoofing for development/testing (allows venue-based testing from home)
  • [X] Create dev-mode override in Firebase config
  • [X] Add VITE_DEV_TEST_LOCATION environment variable (latitude, longitude) for test venue
  • [X] Add mock/override for navigator.geolocation in test setup
  • [X] Create debug panel in ProfileSettings (dev-only) to spoof location
  • [X] Document location spoofing setup in ENVIRONMENT_SETUP.md
  • [ ] Verify end-to-end encrypted profile transit: ensure birth date is encrypted before any network transmission
  • [ ] Add encryption/decryption tests for profile data persistence
  • [ ] Ensure Firestore security rules prevent ANY plaintext read of encrypted profile fields
  • [ ] Implement backup codes for account recovery (printed at signup)
  • [ ] Add passphrase hint feature (optional, encrypted)
  • [ ] Build age verification with client-side computation + signature
  • [ ] Add field-level encryption in Firestore for birth dates (wire to Firebase)
  • [ ] Add in report/block functionality
  • [ ] In-app safety tips
  • [ ] Partnership with venues for on-site safety
  • [ ] Implement zero-knowledge proof layer for wave acceptance (verify without decrypting)
  • [ ] Safety Mechanics - Block Functionality (See docs/features/safety/SAFETY_MECHANICS.md)
    • [ ] Create blockService.js with blockUser, unblockUser, getBlockedUsers, isUserBlocked functions
    • [ ] Add Firestore data model for blocks collection
    • [ ] Implement Firestore security rules for block privacy (users can only see their own blocks)
    • [ ] Add block button to Chat.jsx menu (Shield icon, confirmation modal)
    • [ ] Add block button to WaveManager.jsx wave notifications
    • [ ] Build BlockedUsersList component in ProfileSettings.jsx
    • [ ] Implement bidirectional invisibility (blocked users cannot see each other)
    • [ ] Add cross-device block list sync via Firestore listeners
    • [ ] Implement pattern detection: flag users receiving 5+ blocks in 30 days
    • [ ] Test: Block user → verify they disappear from lanterns, waves, chats
  • [ ] Safety Mechanics - SOS Emergency System (See docs/features/safety/SAFETY_MECHANICS.md)
    • [ ] Create sosService.js with activateSOS, deactivateSOS, subscribeToSOSStatus functions
    • [ ] Create recordingService.js for audio/video recording (Web APIs)
    • [ ] Create emergencyContacts.js for contact management and notifications
    • [ ] Add SOS button to DashboardNavigation (AlertOctagon icon, red, prominent)
    • [ ] Build SOSActivationModal component (two-stage confirmation)
    • [ ] Build SOSActiveNotification component (persistent, shows recording status)
    • [ ] Implement emergency contact management in ProfileSettings.jsx
    • [ ] Add Firestore data model for sos_incidents and emergency_contacts collections
    • [ ] Implement GPS location sharing during active SOS
    • [ ] Integrate SMS/push notifications to emergency contacts
    • [ ] Add safe spaces alerting (nearest partner organization)
    • [ ] Implement SOS deactivation with PIN/passphrase requirement
    • [ ] Add incident report form (post-deactivation)
    • [ ] Legal review: Recording consent, terms of service updates
    • [ ] Test: Activate SOS → verify recording starts, location shared, contacts notified
  • [ ] Safety Mechanics - Safe Spaces Partnership Program (See docs/features/safety/SAFETY_MECHANICS.md)
    • [ ] Design partnership application form and vetting process
    • [ ] Create legal agreements and liability waivers for partner organizations
    • [ ] Add safe spaces data model to venueService.js (isSafeSpace, safeSpaceType, services, etc.)
    • [ ] Create safeSpacesService.js with getNearestSafeSpaces, alertSafeSpace functions
    • [ ] Add Firestore collection for safe_spaces with encrypted contact details
    • [ ] Identify and onboard 5-10 safe spaces in San Diego (pilot city):
      • [ ] LGBTQ+ centers (The San Diego LGBT Community Center)
      • [ ] Domestic violence shelters (YWCA, Center for Community Solutions)
      • [ ] Mental health crisis centers (Crisis House, Access & Crisis Line)
    • [ ] Implement safe space search and map view (opt-in, respects confidential addresses)
    • [ ] Build safe space alerting system for SOS activations
    • [ ] Implement funding tracking system (safe_space_funding collection)
    • [ ] Set up monthly donation mechanism (5% of revenue baseline)
    • [ ] Create transparency report template for quarterly publication
    • [ ] Test: User activates SOS → nearest safe space receives alert with approximate location
  • [ ] Safety Mechanics - In-App Safety Education (See docs/features/safety/SAFETY_MECHANICS.md)
    • [ ] Create SafetyTipsPanel component (accessible from ProfileSettings → Safety & Privacy)
    • [ ] Add contextual safety prompts:
      • [ ] Before first lantern light: "Safety Reminder: Only meet in public places"
      • [ ] Before accepting first wave: "You can block or report this user at any time"
      • [ ] When scheduling late-night light (after 10pm): "Stay safe! Share your plans with a friend"
    • [ ] Add crisis hotline links to Safety Tips:
      • [ ] National Domestic Violence Hotline: 1-800-799-7233
      • [ ] Trans Lifeline: 1-877-565-8860
      • [ ] RAINN Sexual Assault Hotline: 1-800-656-4673
      • [ ] Suicide Prevention Lifeline: 988
      • [ ] Crisis Text Line: Text HOME to 741741
    • [ ] Implement multilingual safety tips (Spanish, Mandarin for San Diego pilot)
    • [ ] Add "Recognize Scams" section (asking for money, personal info, phishing)
    • [ ] Test: Navigate to Safety Tips → verify all content displays correctly
  • [ ] Safety Mechanics - Platform Bans & Re-Registration Prevention (See docs/features/safety/SAFETY_MECHANICS.md)
    • [ ] Create banService.js with account suspension and ban management functions
    • [ ] Add Firestore data model for banned_accounts collection with hashed identifiers
    • [ ] Implement ban severity levels (Warning, Temporary Suspension, Shadow Ban, Permanent Ban)
    • [ ] Build moderation dashboard for reviewing flagged accounts
    • [ ] Implement automated triggers (5+ blocks → flag, 10+ blocks → temp suspension)
    • [ ] Build manual review workflow for moderation team
    • [ ] Implement appeals process (appeals@ourlantern.app, 30-day window)
    • [ ] Re-Registration Prevention - Layer 1: Email/phone verification and hash-based ban extension
    • [ ] Re-Registration Prevention - Layer 2: Device fingerprinting (browser fingerprint, installation ID)
    • [ ] Re-Registration Prevention - Layer 3: Behavioral fingerprinting (typing patterns, wave timing, navigation)
    • [ ] Re-Registration Prevention - Layer 4: Social graph analysis (connection patterns, mutual friends)
    • [ ] Re-Registration Prevention - Layer 5: Payment method banning (if monetization added)
    • [ ] Implement account creation check (hash email/phone, check device fingerprint before allowing signup)
    • [ ] Build false positive mitigation (require 2+ signals, manual review for edge cases)
    • [ ] Create community guidelines document (clear policy violations and severity levels)
    • [ ] Build ban notification system (email with reason, appeals path, duration)
    • [ ] Implement shadow ban UX (user sees normal app but is invisible to others)
    • [ ] Add GDPR/CCPA compliance for ban data retention (1-year retention, right to erasure)
    • [ ] Create transparency reporting (quarterly aggregate ban statistics)
    • [ ] Test: Banned user tries to create new account → verify detection and prevention
    • [ ] Monitor effectiveness metrics (ban evasion rate, false positive rate, appeal overturn rate)
    • [ ] Encryption & Security Verification (See docs/features/safety/SAFETY_MECHANICS.md - Encryption & Security Implementation)
      • [ ] Implement bcrypt hashing for email/phone in banService.js (cost factor 10)
      • [ ] Implement SHA-256 hashing for device fingerprints in deviceFingerprint.js
      • [ ] Implement AES-256-GCM encryption for safe space contacts (server-side Cloud Function)
      • [ ] Set up Firebase Secret Manager for encryption key storage
      • [ ] Implement key rotation (automated every 90 days)
      • [ ] Write Firestore security rules: ban database read/write blocked for clients
      • [ ] Write Firestore security rules: safe_spaces/private subcollection never readable by clients
      • [ ] Write hash verification tests (verify bcrypt output cannot be reversed)
      • [ ] Write encryption roundtrip tests (encrypt → decrypt with active SOS only)
      • [ ] Write Firestore rules tests (verify unauthorized reads fail)
      • [ ] Set up monitoring for suspicious decryption patterns (>100 decryptions/24hr)
      • [ ] Conduct security code review of all encryption modules
      • [ ] External penetration testing: attempt to reverse hashes from database export
      • [ ] Database export audit: scan for plaintext PII (automated monthly)
      • [ ] Log analysis: scan for emails/phones in application logs (automated)
      • [ ] Dependency CVE scanning: GitHub Dependabot for bcrypt/crypto vulnerabilities
      • [ ] Document encryption in User Security Guide (transparency about hashing/encryption)
  • [ ] Implement zero-knowledge proof layer for wave acceptance (verify without decrypting)
  • [ ] Implement Signal Protocol for message E2E encryption
  • [ ] Add encrypted metadata / sealed sender support
  • [ ] Network activity encryption
  • [ ] Security audit of encryption.js by external expert
  • [ ] Penetration testing of authentication flow
  • [ ] Set up security@ourlantern.app email for vulnerability reports
  • [ ] Implement bug bounty program
  • [ ] Confirm that site cannot be accessed, crawled or indexed while cloudflare policy is enabled

Location Security & Anti-Fraud ​

Context: Location-based features (Waves, check-ins, proximity matching) are core to Lantern but create serious security/abuse risks. All location data must be validated server-side to prevent spoofing, stalking, and merchant fraud.

Privacy Model: Use location ephemerally (proximity checks, venue verification) but NEVER retain location history. Client sends location → server validates → server responds → location discarded.

Phase 1: Critical (Before Production Launch) ​

Priority: BLOCKER - These must be implemented before any location-based features go live.

  • [ ] Server-side location validation (Firebase Cloud Function)
    • [ ] Validate coordinate ranges: latitude (-90 to 90), longitude (-180 to 180)
    • [ ] IP geolocation cross-check: compare GPS coords to IP location (allow 50km variance for VPN/mobile towers)
    • [ ] Log suspicious activity: flag mismatches >50km for review
    • [ ] Return validation result: accept/reject location claim
  • [ ] Input sanitization for location data
    • [ ] Strict type checking for lat/lng (floats only)
    • [ ] Sanitize any venue metadata (names, addresses) for XSS prevention
    • [ ] Reject malformed location payloads
  • [ ] Backend logging audit
    • [ ] Ensure location coordinates NOT logged in application logs
    • [ ] Verify location data NOT persisted in Firebase (except ephemeral check-ins with 48hr TTL)
    • [ ] Confirm no location data in error messages or stack traces
  • [ ] Documentation updates
    • [ ] Document location security threat model in SECURITY_ARCHITECTURE.md
    • [ ] Add "Location Privacy" section to USER_SECURITY_GUIDE.md
    • [ ] Update privacy policy with ephemeral location processing language
    • [ ] Add location spoofing prohibition to Terms of Service

Phase 2: Important (First 3 Months Post-Launch) ​

Priority: HIGH - Implement once fraud patterns emerge from real usage.

  • [ ] Velocity checks (teleportation detection)
    • [ ] Track last known location and timestamp per user
    • [ ] Calculate distance between location updates
    • [ ] Flag impossible travel: >100 miles in <5 minutes
    • [ ] Auto-suspend accounts with repeated violations
  • [ ] Rate limiting for location-based actions
    • [ ] Max 10 venue check-ins per hour per user
    • [ ] Max 20 waves per hour per user
    • [ ] Max 3 location updates per minute
    • [ ] Return 429 Too Many Requests with retry-after header
  • [ ] Stalking pattern detection
    • [ ] Track venue co-location frequency between user pairs
    • [ ] Flag users who "coincidentally" check into same venues as another user >5 times/week
    • [ ] Alert moderation team for manual review
    • [ ] Implement shadow banning for confirmed stalkers (don't show in Lantern Hub)
  • [ ] Merchant fraud detection
    • [ ] Track check-in patterns: flag users with >20 check-ins/day
    • [ ] Detect time-of-use violations: check-ins outside venue hours
    • [ ] Implement fraud scoring system (0-100) per user
    • [ ] Auto-disable offer redemption for high-risk users (score >80)

Phase 3: Enhanced (As Needed Based on Abuse) ​

Priority: MEDIUM - Advanced protections if basic mitigations prove insufficient.

  • [ ] WiFi network verification for check-ins
    • [ ] Venue provides WiFi SSID/BSSID to Lantern backend
    • [ ] User device reports connected WiFi network during check-in
    • [ ] Server validates user is on venue's WiFi network
    • [ ] Fallback to GPS-only validation if WiFi unavailable
  • [ ] Bluetooth beacon proximity verification
    • [ ] Deploy physical Bluetooth beacons at partner venues
    • [ ] User device detects beacon during check-in (RSSI signal strength)
    • [ ] Server validates beacon proximity (strong signal = physically present)
    • [ ] More reliable than GPS indoors (GPS weak in buildings)
  • [ ] Machine learning fraud scoring
    • [ ] Train ML model on labeled fraud/legitimate check-in data
    • [ ] Features: time patterns, location patterns, velocity, IP reputation
    • [ ] Real-time scoring during check-in request
    • [ ] Adaptive thresholds based on venue risk profile
  • [ ] Geofencing validation
    • [ ] Define precise geofences for high-value venues (merchant partners)
    • [ ] Server-side geofence containment check (not client-side)
    • [ ] Require minimum GPS accuracy (e.g., ±20 meters) for check-in
    • [ ] Reject check-ins with low accuracy to prevent wide-area spoofing

Incident Response & Monitoring ​

  • [ ] Create location fraud incident playbook
    • [ ] Detection: automated alerts for velocity violations, stalking patterns, fraud scoring
    • [ ] Investigation: manual review process, evidence collection
    • [ ] Response: account suspension, data deletion, law enforcement referral (stalking)
    • [ ] Communication: notify affected users (stalking victims), transparency report
  • [ ] Dashboard for location abuse metrics
    • [ ] Real-time alerts for velocity violations (Slack/email)
    • [ ] Weekly fraud report: flagged users, patterns, trends
    • [ ] Stalking detection alerts with user pair identifiers
    • [ ] Merchant fraud dashboard per venue
  • [ ] Security audit of location features
    • [ ] External penetration test of location validation endpoints
    • [ ] Code review of geolocation handling (client + server)
    • [ ] Threat modeling workshop with security experts
    • [ ] Bug bounty program for location spoofing vulnerabilities

Attack Vector Documentation ​

  • [ ] Document location spoofing attack scenarios
    • [ ] Browser DevTools GPS override (trivial)
    • [ ] GPS spoofing apps (Android root/iOS jailbreak)
    • [ ] VPN + fake GPS coordinates
    • [ ] Proxy/VPN to match IP location to fake GPS
  • [ ] Document stalking attack scenarios
    • [ ] Repeated check-ins at victim's frequented venues
    • [ ] Wave harassment at known locations
    • [ ] Physical surveillance aided by Lantern data
  • [ ] Document merchant fraud scenarios
    • [ ] Offer redemption without physical presence
    • [ ] Automated check-in bots for offer farming
    • [ ] Coordinated fraud rings across multiple accounts

Privacy-Preserving Alternatives (Research) ​

  • [ ] Differential privacy for location aggregates
    • [ ] Add noise to "X people at this venue" counts
    • [ ] Prevent inference of individual presence from aggregate data
  • [ ] Homomorphic encryption for proximity checks
    • [ ] Compute proximity without revealing exact coordinates to server
    • [ ] Requires significant computational overhead (feasibility research)
  • [ ] Zero-knowledge proofs for location claims
    • [ ] Prove "I am within 50ft of user X" without revealing exact location
    • [ ] Cryptographic proof prevents spoofing but allows privacy

Social Features ​

  • [ ] Create ability for adding friends
  • [ ] Implement friend profile viewing with privacy controls
  • [ ] Add friend activity notifications
  • [ ] Implement friend request system with encryption
  • [ ] Create encrypted messaging with friends
  • [ ] Add friend lantern lighting preferences

Bonfire (Group Feature) ​

This feature allows 2 currently connected users to light a "Bonfire" that other individuals can wave to and join.

  • [ ] Create initial feature configuration
  • [ ] Create documentation
  • [ ] Implement encrypted bonfire creation and management
  • [ ] Add bonfire discovery and joining mechanics
  • [ ] Create bonfire activity notifications

Merchant Community ( Feature ) ​

  • [ ] Allow for merchants to open up "communities" that users can join. This is a maybe and we have to account for privacy considerations

User Retention & Engagement ​

  • [ ] Push notifications (when friends are at nearby venues)
  • [ ] Weekly merchant offers
  • [ ] In-app notifications for wave activity
  • [ ] Gamification (discover 10 venues this month badges)
  • [ ] Leaderboards and achievement system
  • [ ] Seasonal events and challenges
  • [ ] Referral rewards program

Tools & Developer Experience ​

  • [ ] Clarify documentation on Office Viewer extension for markdown files
  • [ ] Set up local development environment automation
  • [ ] Create developer onboarding guide
  • [ ] Add pre-commit hooks for code quality
  • [ ] Implement API client generator (for mobile apps)
  • [ ] Create SDK for third-party integrations
  • [ ] Build CLI tools for venue management

Backend Integration & API ​

Phase 1 (Priority): Firebase Auth integration, profile auto-creation, Firestore security rules, two-device sync testingPhase 2: Full API design, backend server setup, JWT auth, cross-platform data syncPhase 3: Production features (merchant APIs, age verification, rate limiting, monitoring)

  • [X] Complete Firebase Auth flow integration in SignupFlow component
    • [X] Connect signup form to Firebase Auth (email/password or custom claims)
    • [X] Add password/passphrase validation and strength checks
    • [X] Implement login form with Firebase Auth
    • [X] Create auto-profile-creation trigger on successful signup
  • [X] Implement Firestore profile auto-creation on signup
    • [X] Cloud Function or Firestore trigger creates user profile document
    • [X] Profile includes: lantern name, encrypted birth date, interests, mood, created_at timestamp
    • [X] Ensure all sensitive fields are encrypted client-side before Firestore write
  • [X] Add Firestore security rules for profile data
    • [X] Users can only read/write their own profile
    • [X] Encrypted fields cannot be queried or exposed in plaintext
    • [X] Age verification data remains encrypted server-side
  • [ ] Test two-device profile sync
    • [ ] Create second test profile on different device/browser
    • [ ] Verify profile data syncs in real-time between devices
    • [ ] Test offline data sync when connection returns
  • [ ] Implement location spoofing for cross-device testing (see Security section)
    • [ ] Deploy test version with dev location override
    • [ ] Test lantern lighting at "home venue" from multiple devices
  • [ ] Design API contract (endpoints, request/response schemas) for web + mobile platforms
  • [ ] Switch from hash-based routing (#/signup) to History API routing (/signup) when backend ready
  • [ ] Set up backend server (Node/Express, Python/Django, etc.)
  • [ ] Implement authentication system (JWT tokens, refresh tokens, session management)
  • [ ] Create user API endpoints (signup, login, profile management)
  • [ ] Integrate Firebase or alternative for real-time data sync
  • [ ] Implement data sync across web, iOS, and Android clients
  • [ ] Set up backend database schema for user profiles, conversations, lanterns, offers
  • [ ] Wire real API calls to replace stubbed endpoints in OfferForm and merchant dashboard
  • [ ] Implement server-side age verification for venue access
  • [ ] Add server-side validation for encrypted profile data
  • [ ] Set up API rate limiting and abuse prevention
  • [ ] Implement background job system for notifications and data cleanup
  • [ ] Create API documentation (OpenAPI/Swagger)
  • [ ] Add API error handling and logging
  • [ ] Implement API versioning strategy
  • [ ] Set up API monitoring and error tracking

Infrastructure & Deployment ​

  • [X] Acquire domain: ourlantern.app
  • [X] Set up Cloudflare (Free plan)
  • [X] Configure DNS: ourlantern.app (production) and dev.ourlantern.app (development)
  • [X] Create two Pages projects: lantern-app (prod) and lantern-app-dev (dev)
  • [X] Configure Cloudflare Access with three apps: production, development, wildcard catch-all
  • [X] Set up environment variables for both Pages projects
  • [X] Verify deployments working: ourlantern.app (main) and dev.ourlantern.app (dev)
  • [ ] Monitor infrastructure costs and usage patterns
  • [ ] Set up error tracking and alerting
  • [ ] Analyze traffic patterns and optimize Cloudflare caching
  • [ ] Implement CDN for static asset delivery
  • [ ] Cloudflare plan upgrade trigger (6-12 months): Only upgrade to Pro if bot attacks or abuse becomes a problem
  • [ ] Cloudflare plan upgrade trigger (18+ months): Upgrade to Business if handling payments (PCI/SOC 2 compliance required) or SLA uptime guarantees needed
  • [ ] Implement PCI/DSS compliance for payment processing (if applicable)
  • [ ] Set up SOC 2 audit trail and documentation

Mobile Apps ​

  • [ ] Begin iOS app development (uses same Firebase backend)
  • [ ] Begin Android app development (uses same Firebase backend)
  • [ ] Set up mobile CI/CD pipelines
  • [ ] Submit iOS app to App Store
  • [ ] Submit Android app to Google Play Store
  • [ ] Implement auto-update mechanisms
  • [ ] Set up mobile app analytics

Transparency & Communication ​

  • [ ] Add info that we do use AI to efficiently build our systems, but we still make the best effort to manually review our configurations AND the system design is manually configured
  • [ ] Create detailed cost breakdown documentation
  • [ ] Document all third-party dependencies and their purposes
  • [ ] Publish security audit results and findings
  • [ ] Establish transparency report publication schedule
  • [ ] Create community feedback channels
  • [ ] Publish data usage statistics and privacy metrics
  • [ ] Publish cost and revenue
  • [ ] Add CHANGELOG.md when approaching public release
    • [ ] Use Keep a Changelog format
    • [ ] Include in VitePress sidebar under Development section
    • [ ] Consider conventional-changelog for automation from git commits
    • [ ] Implement when: public release/beta, semantic versioning, breaking changes, or merchant/partner communication needs

General Notes & Technical Debt ​

  • [ ] Once a user leaves their lantern vicinity, their lantern is extinguished
  • [ ] Implement venue-based context awareness across all features
  • [ ] Add comprehensive error handling and user-friendly error messages
  • [ ] Review and update API documentation to ensure all endpoints are covered and examples are provided
  • [ ] Ensure that the PWA testing steps are clear and include any necessary tools or configurations
  • [ ] Verify that the tech stack documentation is up-to-date with any new technologies or practices adopted in the project
  • [ ] Add a section for testing best practices, including unit tests and integration tests
  • [ ] Create architectural decision records (ADRs) for major design choices
  • [ ] Maintain up-to-date runbooks for common operational tasks

Built with VitePress

Copyright © 2026 Lantern