Inspiration
Dating apps often ask people to trade privacy for participation: a phone number, precise location, readable conversations, and an engagement-optimized swipe feed. OpenDating explores a smaller, calmer model where members own their identity and understand each disclosure before making a choice.
What it does
OpenDating presents one deliberate introduction at a time. Each introduction explains the visible compatibility facts behind it and includes a privacy receipt showing what is shared, withheld, and unlocked only after mutual interest. Interest is private, and a conversation opens only after both people choose each other.
Members create a self-owned account without email, phone number, or social login. Exact GPS is reduced on-device to an approximate 5 km area before discovery. Matched conversations use end-to-end encryption. The app also includes blocking, private reporting, visibility controls, recovery-key backup, and permanent account deletion.
OpenDating Plus is an optional $4.99 lifetime purchase powered by RevenueCat. It unlocks Sage, Ocean, and Plum accent themes. It never changes discovery, ranking, matching, messaging, recovery, deletion, or safety.
How we built it
The client uses Expo Router, React Native, and strict TypeScript. Nostr provides the identity and cryptographic building blocks, while the OpenDating protocol defines profiles, discovery, private choices, matches, moderation, and encrypted messages. A Cloudflare Worker operates the relay and media services. RevenueCat validates the lifetime Plus entitlement using an opaque billing identifier; profile, location, recovery-key, safety, and message content is not sent to RevenueCat.
The browser build uses an encrypted local identity vault so the real app can be tested without a native install. The private recovery key is encrypted with AES-256-GCM using a PBKDF2-derived browser-lock key and is never persisted in plaintext.
Challenges
The hardest boundary was making a decentralized identity understandable and recoverable without turning the recovery key into a normal password. We also had to keep coarse location, encrypted messaging, moderation, browser storage, and StoreKit entitlement state explicit across degraded-network and locked states.
Apple declined the first iOS candidate under Guideline 4.3(b). We replaced the swipe-first experience with deliberate private introductions, privacy receipts, and a Privacy Passport before preparing a fresh release.
Accomplishments
- One explained introduction instead of an endless swipe feed
- A live Privacy Passport for identity, visibility, and disclosure boundaries
- Coarse-location discovery without transmitting raw GPS
- Match-only end-to-end encrypted conversations
- Operational report, block, unmatch, feedback, and deletion paths
- A browser app with an encrypted recovery-key vault
- A non-consumable Plus product that sells customization, not dating outcomes
What we learned
Privacy works better as an interaction than as a policy page. Showing a privacy receipt at the moment of an introduction makes the boundary understandable. Likewise, a portable identity needs visible backup, lock, and deletion controls to feel trustworthy rather than merely decentralized.
How we used AI
Cloudflare Workers AI screens only profile display names and bios for obvious safety-policy violations before publication. It does not process photos, location, recovery keys, likes, matches, reports, or encrypted messages. Codex was used to inspect the repository, implement and review changes, run tests, and verify deployment and release artifacts.
What's next
Complete physical-device purchase validation and publish the revised iOS build. Federation and independent service providers remain post-hackathon work.
Built With
- cloudflare-workers
- cloudflare-workers-ai
- expo.io
- nostr
- react-native
- revenuecat
- typescript
Log in or sign up for Devpost to join the conversation.