Last updated: 2026-04-19
The big picture
Most apps that “find people nearby” either need an account, harvest your data, or only show you faces and force you to swipe. Vicinity does none of that. It finds people who share your interests, who are physically nearby right now, without telling anyone — including us — what you’re interested in.
The shape of your evening can change because someone in the same coffee shop turns out to be a 92% match.
Two reasons. First, the moment you allow proximity matching to mean “anywhere in the city”, you need accounts, location servers, and the same swipey UX as every other app. Vicinity skips all that. Second, real-world serendipity is more interesting: matching with someone you can actually go say hi to right now changes the social dynamic completely.
Profiles are how dating apps reduce people to a swipeable card. We don’t want that. There are also no photos because photos require accounts and storage, both of which would compromise the privacy model. There’s no chat because real conversations should happen in person — Vicinity gets you to “hello”, and you take it from there.
This isn’t a dating app. It’s a “compatible person nearby” detector.
Privacy
The app makes one promise: your interest ratings never leave your phone in readable form. That’s enforced by mathematics, not by us promising not to look. Two phones can compute how compatible they are, with each other, without either phone learning what the other phone actually likes.
Specifically:
• The Vicinity app contacts no servers. There is no Vicinity backend.
• We collect no analytics, crash reports, or telemetry.
• We have no user accounts; there is no profile of you stored anywhere.
• The only place data flows off your device is to other Vicinity phones in Bluetooth range — and that data is encrypted in a way the receiving phone cannot decrypt.
That’s the one and only piece of personal data Vicinity collects, and only during the closed beta. It’s stored on the website’s own server, used to send you beta builds, and deleted when the beta ends. The full details are in the Privacy Policy.
This is the most-asked question and we sympathise — Android forces it on us. Any app that scans for Bluetooth devices is required by the Android operating system to hold the Location permission, even if it never reads your location. Vicinity does not call any location API anywhere in the code; we use the permission only because the OS requires it for Bluetooth scanning.
A determined attacker with multiple Bluetooth scanners around a city could, in theory, fingerprint your encryption key and follow your movements. We mitigate this by rotating your encryption key periodically (default: daily).
The cryptography
Normally, to compute on data, you have to decrypt it first — which means whoever is computing must be allowed to see the data. Homomorphic encryption breaks that rule: it lets you compute on encrypted data directly and get an encrypted result, which only the original key-holder can decrypt.
Vicinity uses the Paillier homomorphic cryptosystem. The two phones exchange encrypted vectors of their interest ratings, each does a math operation on the other phone’s encrypted vector to produce a compatibility score, and only the original phone can decrypt the final score it gets back. Neither side ever sees the other’s plaintext interests.
• RSA isn’t homomorphic in a useful way for this — you can’t add two encrypted numbers and get an encrypted sum.
• Fully homomorphic encryption (FHE) can do anything, but it’s orders of magnitude slower — running an FHE comparison on a phone over Bluetooth would take minutes, not seconds.
• Paillier is “additively homomorphic” — it natively supports adding encrypted numbers, which is enough for the compatibility computation we do (squared Euclidean distance, which boils down to additions and multiplications by known constants). It’s fast: an exchange completes in 2–4 seconds on mid-range phones.
Other approaches we considered and rejected: Goldwasser–Micali, garbled circuits, secure multi-party computation.
For long-term server-stored data, yes. But for an ephemeral Bluetooth exchange that completes in seconds and uses fresh keys daily, 1024-bit Paillier provides ample security headroom and runs noticeably faster on mobile (where the limiting factor is CPU, not network). We tested 2048-bit — exchanges took 8–15 seconds, occasionally aborting on slower devices. We deemed that unusable.
If we just returned an exact compatibility score, an attacker could in principle rate themselves carefully across many encounters and triangulate your exact ratings — a “differential attack”. Vicinity injects small random noise (Gaussian, σ=3 in the squared-distance space) into every result, then displays the score in 5% buckets. The noise is small enough not to materially change a “you’re 87% compatible” answer, but enough to make differential reconstruction infeasible across realistic encounter counts.
Bluetooth / proximity
• GPS+server: requires us to run a server, gives us location data we don’t want. No.
• Wi-Fi Direct: not designed for ad-hoc passive discovery between strangers; UX is clunky.
• Ultrasound: works at concert distances at best, no battery savings, and triggers some users’ devices unpredictably.
• NFC: requires devices to literally touch. Not “in the same coffee shop” friendly.
• Bluetooth Low Energy (BLE): power-efficient, ~10-metre range, designed for ad-hoc discovery without pairing, supported on every modern Android phone. Perfect fit.
Roughly 10 metres line-of-sight, less through walls or furniture. So same coffee shop, same lecture hall, same train carriage — yes. Different rooms in the same building — usually no.
Less than you’d expect. BLE is designed to be low-power; the app spends most of its time in low-duty-cycle scan mode. Our heaviest battery user is the foreground service notification (which Android requires), not the radio. We aim for sub-1% per hour additional drain from active discovery.
iOS deliberately restricts the use of Bluetooth Low Energy by third-party apps in the background. Specifically, Apple does not let apps advertise the kind of custom service identifier Vicinity needs while the app is not in the foreground. This means an iOS Vicinity user would have to keep the app open and on-screen for the app to be discoverable — a non-starter for “background passive discovery” UX.
We’re not opposed to iOS in principle; we’re opposed to shipping a broken iOS app that pretends to work but doesn’t.
The matching algorithm
You rate 11 interest categories from “thumbs down” (you actively dislike it) through “neutral” to “love it”. Internally we map these to numbers from −3 to 5 (the thumbs-down counts heavily because mismatched dislikes are a strong signal). When two phones exchange, each computes the squared Euclidean distance between the two rating vectors — small distance means similar tastes. Distance is then converted to a percentage from 0% to 100%.
It’s deliberately simple. We considered weighted models, learned embeddings, and personality dimensions; we chose simple because everyone can understand it and there’s no model to second-guess.
The categories are deliberately activity and lifestyle axes, not opinion or attitude axes. Research consistently shows that shared activity preferences are a stronger predictor of friendship formation than shared opinions — two people who both love hiking form bonds; two people who agree about politics don’t necessarily get along. So the categories map to things you can actually do: physical (Sports & Fitness, Outdoors & Nature), social/cultural (Music & Nightlife, Food & Drink Culture), intellectual (Reading & Ideas, News & Current Affairs), creative (Creative Arts, Film & TV), and so on.
11 sits in the 8–12 range validated by psychometric instruments — the Leisure Interest Measure uses 8 domains, Schwartz values uses 10, Bumble uses 12 meta-categories. Enough dimensions to meaningfully differentiate two people; few enough to fill in within two minutes. The 11 axes are also genuinely independent: knowing you love hiking tells you nothing about whether you follow the news.
One thing that surprises people: News & Current Affairs measures engagement level, not political convictions. Someone who follows the news closely and enjoys discussing current events is compatible with another news-follower, regardless of their politics. Two people who disagree politically but both love engaging with current events have more in common than a news-junkie and someone who tunes out entirely. That’s an activity-preference signal — the same logic as Sports & Fitness.
Because “we both love opera” tells you less than “we both hate sports bars” — agreement on dislikes is often the stronger compatibility signal. We weight thumbs-down at −3 (vs +5 for “love”) to reflect that. A profile of all thumbs-up gives bland matches; a profile that takes a stance via thumbs-downs gives sharper, more meaningful ones. The app gives you a gentle nudge during onboarding if you avoid using thumbs-down.
They’ll never match. The app embeds a hash of the active category list in its Bluetooth advertisement; if your phone’s list doesn’t match the other phone’s, they won’t even attempt an exchange. This guarantees no apples-to-oranges comparisons across app versions or flavours.
Identity and remembering people
It uses a fingerprint derived from the public part of your encryption key — specifically, the SHA-256 hash of the key. Two encounters with the same phone (while it's using the same key) produce the same fingerprint. The app uses this for a few things:
• Cooldowns — so you don't get matched with the same person every minute
• Encounter count — "Seen 3 times"
• Labels and mutes — any nickname you've attached to that device, or a mute flag, travels with the fingerprint (see "Can I label or mute someone I've matched with?" below)
What the fingerprint is not: it's not an identity. It's a hash of a randomly-generated encryption key that rotates periodically (daily by default). There is no registry — anywhere, on our side or anyone else's — mapping fingerprints to names, phone numbers, or accounts. Once your key rotates, your old fingerprint becomes a dead identifier: someone who saw you yesterday as fingerprint A3B9… will, from tomorrow, see a completely different fingerprint that doesn't link back.
Any other Vicinity phone in Bluetooth range sees your fingerprint (it's derived from the public key you broadcast, so that's unavoidable), but that fingerprint is meaningless outside the narrow social context of the app — it doesn't expose your identity, your movements, or any personal data. We mitigate the risk of a determined attacker running a scanner network to track fingerprints over time with key rotation, which is covered in more detail above ("Could a fake / malicious Vicinity app track me?").
Two reasons. First, it limits how long a determined attacker could fingerprint you across multiple Bluetooth scanners. Second, it gives users a clean way to "reset" their Vicinity identity without losing local data.
You can change the rotation interval in Settings — anywhere from "every time you start discovery" to "weekly" to "never".
Yes — tap any row in your match feed. Labels (e.g. "coffee shop") and mute settings are stored only on your phone, keyed against the peer's fingerprint. Mute means future matches with that person don't notify you, but you can still find them in your feed. When the peer rotates their key, your label/mute lapses — that's a deliberate property: identity is intentionally short-lived.
How is Vicinity different from [other app]?
They're profile-based dating apps. Vicinity is a proximity-based interest-matcher with no profiles. Different category.
Happn matches "people who crossed paths with you in the recent past" via GPS + their server. Vicinity matches people physically near you right now via Bluetooth, with no server involvement.
Those are for sharing your location with friends. Vicinity is for discovering compatible strangers without sharing any location.
Those are file-sharing peer-to-peer Bluetooth/Wi-Fi tools. Vicinity is a compatibility-discovery tool that happens to also use Bluetooth.
Privacy-focused messaging apps. Vicinity is not a messaging app. We share their privacy values, very different use case.
Things Vicinity deliberately does NOT do
- No accounts. Nothing to sign up for, nothing to log out of, nothing for us to hold against you.
- No photos. They invite swiping behaviour we don't want.
- No chat. Vicinity gets you to "hello"; conversations happen offline.
- No social graph. We don't store who matched whom, anywhere, ever.
- No analytics. No mixpanel, no crashlytics, no nothing.
- No push notifications from a server. Notifications come only from your own phone, when your own Bluetooth scanning finds a match.
- No location tracking. Despite needing the permission, the app contains zero calls to any location API.