Every social app on the market today makes the same promise: "We respect your privacy." They publish lengthy privacy policies, add toggles to settings screens, and run ad campaigns about how much they care about your data. Then they collect everything anyway. Location history, contact graphs, behavioral fingerprints, message metadata — all of it funneled into advertising models that treat your social life as raw material.

We think this approach is fundamentally broken. Not because companies have bad intentions (though some do), but because privacy policies are just words. They can be changed, reinterpreted, overridden by acquisition, or simply ignored. The only meaningful guarantee is architectural: if the system cannot track you, then no policy change, rogue employee, or government subpoena can reverse that decision.

This is the principle behind Serendipity's zero-knowledge architecture. We didn't build a social app and then add privacy features. We started with a constraint — the server must be unable to identify, locate, or profile any user — and built the social experience around it.

Why Privacy Policies Are Meaningless

Consider what happens when a traditional social app tells you it "doesn't sell your data." That statement might be technically true while the company still shares your data with partners, uses it to train models, or builds internal advertising profiles. The privacy policy is a legal document, not a technical one. It describes what the company says it will do, not what the system can do.

Here's a concrete example. A dating app might promise it doesn't share your exact GPS coordinates with other users. But if the server stores those coordinates — even temporarily — they exist in a database that can be breached, subpoenaed, or accessed by insiders. In 2024 alone, multiple dating apps exposed user location data through API vulnerabilities that researchers had warned about for years.

The zero-knowledge alternative is simple in principle: never send the coordinates to the server in the first place. If the server never receives your location, there is no database to breach and no log to subpoena. The privacy guarantee isn't a promise — it's a mathematical fact.

Architecture is policy that can't be lobbied away. If the server never receives the data, no policy change can expose it.

Rotating Beacon IDs: Ephemeral Identity at the Bluetooth Layer

Bluetooth Low Energy (BLE) is the foundation of proximity-based social discovery. Your phone broadcasts a signal, nearby phones detect it, and some kind of matching can occur. The problem is that a static BLE identifier acts as a tracking beacon. Anyone — a stalker, an advertiser, a state actor — can monitor a static Bluetooth ID to track your movements across space and time.

Serendipity eliminates this attack vector with rotating beacon IDs built on ephemeral cryptographic keypairs. Here's how it works:

The Rotation Mechanism

Every 15 minutes, your device generates a fresh X25519 keypair. The keypair is ephemeral — the private key never leaves the device's secure enclave, and the public key is used to derive a short beacon identifier:

beacon_id = SHA-256(public_key || epoch_number)[0:8]

The epoch_number is simply the current 15-minute window expressed as an integer (Unix timestamp divided by 900). The beacon ID is the first 8 bytes of the SHA-256 hash of the public key concatenated with this epoch number. This gives us a 64-bit identifier that is unique to this device for this 15-minute window and is computationally unlinkable to the previous or next window's identifier.

Why This Prevents Tracking

An observer who records beacon ID a3f7c901e2b84d6f at 2:00 PM and beacon ID 19d4e8b3770a2c51 at 2:15 PM has no way to determine whether these came from the same device. The hash function is one-way: you cannot derive the public key from the beacon ID, and you cannot link two beacon IDs without knowing both underlying public keys. Since the keypairs are generated independently every 15 minutes, the identifiers are cryptographically independent.

This is a stronger guarantee than what Apple and Google provide in their Exposure Notification framework. Their rotating identifiers are derived from a single daily key, meaning that anyone who obtains the daily key (as happens during positive COVID reports) can link all of that day's identifiers. Our keypairs are fully independent — there is no master key to compromise.

Mutual Discovery Without Linkability

When two Serendipity users come within BLE range, their devices perform an X25519 Diffie-Hellman key exchange using the current ephemeral keypairs. This produces a shared secret that both devices can derive independently without transmitting it. The shared secret becomes the basis for encrypted communication during that encounter.

shared_secret = X25519(my_private_key, their_public_key)
session_key   = HKDF-SHA256(shared_secret, "serendipity-session-v1")
// Encrypt all further exchange with ChaCha20-Poly1305 using session_key

The relay server sees only encrypted payloads tagged with ephemeral beacon IDs. It cannot decrypt the content, and within 15 minutes, the beacon IDs will rotate and become unlinkable to any future interaction.

On-Device Computation: The Server Sees Nothing

Most social apps perform matching on the server. Your profile, preferences, location, and behavior are uploaded so that a recommendation engine can compare you against millions of other users. This is architecturally convenient but creates a massive honeypot of personal data.

Serendipity inverts this model. The resonance engine — our compatibility scoring system — runs entirely on your device. When two users encounter each other via BLE, their devices exchange encrypted interest vectors and compute a resonance score locally. The server never sees your interests, your scores, or even the fact that a match occurred.

How Resonance Scoring Works On-Device

Each user maintains a local interest profile encoded as a set of weighted tags. When an encounter occurs, the devices exchange these profiles over the encrypted BLE channel. Each device independently computes a resonance score using a weighted cosine similarity algorithm. If both devices compute a score above the user's configured threshold, the match is surfaced in the app. If not, the encounter data is discarded and no record of it is retained anywhere.

The server's role is reduced to acting as an encrypted relay — it forwards opaque blobs between devices when direct BLE communication is interrupted or needs to be continued after the physical encounter ends. It has no ability to inspect, interpret, or act on the content it relays.

Bloom Filters: Interest Matching Without Revealing Interests

There is a subtlety in exchanging interest profiles: even over an encrypted channel, sending your raw interests to another device means that device now knows your interests. For casual encounters, this might be more information than you want to share before deciding to connect.

Serendipity uses Bloom filters to solve this. A Bloom filter is a probabilistic data structure that can test whether an element is a member of a set without revealing the set itself. Each user's interests are hashed into a compact bit array. When two devices exchange Bloom filters, they can compute an approximate overlap score without either device learning the other's specific interests.

// Each interest is hashed into k positions in a bit array of size m
bloom = new BloomFilter(m=256, k=3)
for interest in user_interests:
    bloom.add(SHA-256(interest))

// Exchange bloom filters, compute approximate Jaccard similarity
overlap = popcount(bloom_a AND bloom_b) / popcount(bloom_a OR bloom_b)

The false positive rate is tunable. A small Bloom filter produces more false positives (two users might appear to share an interest they don't), but reveals less about each user's actual interests. We've found that a 256-bit filter with 3 hash functions strikes the right balance between matching accuracy and privacy for the initial encounter phase. Once users mutually decide to connect, they can progressively reveal more detailed profile information at their own discretion.

End-to-End Encryption: X25519 + ChaCha20-Poly1305

Every message, profile fragment, and interaction in Serendipity is end-to-end encrypted. We use X25519 for key agreement and ChaCha20-Poly1305 for symmetric encryption — the same primitives used by Signal, WireGuard, and other security-focused protocols.

Why These Primitives

The relay server handles only ciphertext. It cannot read messages, cannot determine who is talking to whom (because both parties are identified only by rotating beacon IDs), and cannot even determine whether two encrypted blobs belong to the same conversation.

What the Server Can See vs. What It Cannot

Transparency about server knowledge is critical. Many apps claim end-to-end encryption while still collecting extensive metadata. Here's an honest breakdown of what Serendipity's relay server can and cannot observe:

The Server CAN See

  • Encrypted payloads — opaque byte arrays with no structure visible to the server
  • Ephemeral beacon IDs — which rotate every 15 minutes and cannot be linked across rotations
  • Payload size and timing — metadata that reveals only that some device sent some data at some time
  • IP addresses — which we mitigate by not logging them and supporting Tor/VPN connections

The Server CANNOT See

  • User identities — there are no accounts, emails, or phone numbers on the server
  • Locations — GPS coordinates never leave the device
  • Profiles or interests — stored only on-device
  • Message content — encrypted end-to-end, keys are never shared with the server
  • Social graph — the server cannot determine who has matched with whom
  • Encounter history — rotating IDs prevent the server from building movement patterns

This is a fundamentally different security model than apps that encrypt messages but still maintain a server-side social graph, location history, and user profile database.

The Privacy Architecture Table

The following table summarizes where each category of data lives in Serendipity's architecture. The key insight is that sensitive data either stays on-device or passes through the relay only in encrypted form.

Data Type On Device Relay Server Backend
GPS Coordinates Full precision Never transmitted Never stored
Full Profile Complete, plaintext Never transmitted Never stored
Interest Vectors Full detail Bloom filter only (encrypted) Never stored
Messages Plaintext (local) E2E encrypted blobs only Never stored
Encounters Full history Encrypted relay Beacon IDs only (unlinkable)
Glyphs (Reputation) Assigned locally Encrypted transit Anonymous, unlinkable to identity
Resonance Scores Computed locally Never transmitted Never stored

How Other Apps Compare

To appreciate what zero-knowledge architecture means in practice, consider what mainstream social and dating apps typically collect:

Tinder stores your precise GPS coordinates on their servers, maintains a complete history of every swipe and match, logs message content (which they can read), and builds behavioral profiles used for algorithmic ranking. A data subject access request under GDPR reveals hundreds of pages of personal data including timestamps of every app open, location history accurate to meters, and the full text of every conversation.

Facebook constructs a "shadow profile" of information about you that you never provided — inferred from other users' contact books, browsing behavior tracked by the Meta pixel across millions of websites, and facial recognition data harvested from photos others uploaded. Even if you never created an account, Facebook likely has a profile on you.

Bumble and Hinge operate on similar models to Tinder, with server-side matching that requires full access to your preferences, location, and behavioral data. Their privacy improvements are incremental — fuzzing location to the nearest mile instead of the nearest meter — rather than architectural.

These apps could adopt zero-knowledge designs but choose not to because their business models depend on data collection. Ad targeting, algorithmic engagement optimization, and analytics dashboards all require centralized access to user data. Serendipity's architecture makes these business models impossible by design — which is precisely the point.

The Cost of Privacy: Engineering Trade-offs

Zero-knowledge architecture isn't free. There are real engineering costs and user experience trade-offs that we've had to navigate:

These trade-offs are worth it. The alternative — building another data-harvesting social app with a nice privacy policy — is a solved problem that doesn't need another entrant.

Verification: How to Audit a Zero-Knowledge Claim

We don't ask you to trust us. Trust is exactly the thing zero-knowledge architecture is designed to eliminate. Here's how you can verify our claims:

  1. Network traffic analysis. Use a tool like mitmproxy or Wireshark to inspect every byte your device sends. You'll see encrypted blobs and rotating beacon IDs. You won't see GPS coordinates, profile data, or readable text.
  2. Source code review. Our client-side cryptographic operations are open source. You can verify that key generation, rotation, and encryption happen as described.
  3. Beacon ID verification. Monitor your own device's BLE advertisements over time. You'll observe the ID changing every 15 minutes with no correlation between consecutive values.
  4. Server-side minimalism. Our relay server's codebase is small enough to audit in an afternoon. It accepts encrypted blobs, stores them temporarily, and forwards them. There is no analytics pipeline, no recommendation engine, and no profile database.

If we ever violate these architectural commitments, the evidence will be visible in the network traffic. That's the fundamental difference between a privacy policy and a privacy architecture: one requires trust, the other requires only verification.

Conclusion: Architecture as Commitment

The next time a social app tells you they care about your privacy, ask a simple question: could a rogue employee with database access learn who you talked to, where you were, or what you said? For virtually every social app on the market, the answer is yes.

For Serendipity, the answer is no — not because we've written a good privacy policy, but because the data was never there to access. Rotating beacon IDs prevent Bluetooth tracking. On-device computation keeps your interests and matches off our servers. End-to-end encryption ensures that even the messages we relay are opaque to us. And Bloom filters let you discover compatible people nearby without either party revealing their actual interests prematurely.

This is what we mean by zero-knowledge social. Not a marketing phrase, but a verifiable architectural property. The server can't track you because the server doesn't have the data to do so. And that is the only kind of privacy guarantee worth making.