how safety works

A bump should create a connection, not a trail.

weBump uses Bluetooth to notice nearby phones and exchange a tiny identifier that can resolve to a profile. Here is why that identifier cannot stay the same, and what happens from the moment two phones pass.

first, the problem

Imagine your phone broadcast one permanent number.

Say someone puts an inexpensive Bluetooth receiver by a building entrance. It sees number 92841 at 8:12 a.m., again at lunch, and again the next morning. It may not know your name, but the repeated number lets it learn a routine.

Put receivers in several places and those sightings could be linked into a rough movement history. If that same number also opened your profile, the problem would be worse: identity and routine would travel together.

MON 8:1292841 MON 12:3692841 TUE 8:0992841

same signal → linked sightings → learned routine

so we changed the chain

One encounter, in chronological order.

  1. 1

    You turn nearby bumps on.

    Your phone announces weBump, not your profile.

    The Bluetooth advertisement says that a weBump service is nearby. It does not contain your name, friend code, social handles, or the identifier used to retrieve your card.

    Effect: nearby weBump phones know they can connect, while your profile is not sitting in the public advertisement.

  2. 2

    Two phones come close enough to connect.

    They trade temporary rolling IDs.

    Each phone sends a random, opaque identifier over Bluetooth. A rolling ID is not your permanent installation ID or friend code, and a new one takes its place every 15 minutes.

    8:00H7Q4… 8:152KM9… 8:30RX5B…

    Effect: a passive receiver cannot simply look for the same raw ID all day. Linking changing IDs requires active profile resolution through weBump's authenticated, rate-limited server path.

  3. 3

    Your phone wants to turn the rolling ID into a card.

    The server checks the request before revealing anything.

    Profile lookup requires installation credentials stored in the iOS Keychain. Requests are rate-limited, IDs outside a limited resolution window are rejected, self-lookups are blocked, and blocked users cannot resolve one another.

    The server then applies the profile owner's visibility choices. It returns only the fields that person allows a non-friend to see.

    Effect: possessing a Bluetooth ID is not enough to freely browse the database, and a resolved card still obeys its owner's privacy settings.

  4. 4

    The bump is recognized.

    The encounter receipt stays on your phone.

    weBump stores the rolling ID, encounter time, and a broad Bluetooth signal bucket such as “nearby” or “far” in the app's private local storage. The server does not keep a central history of who bumped whom.

    The app keeps at most 200 recent receipts, and you can clear them. Rolling IDs on the server are automatically deleted after their short resolution window.

    Effect: your personal bump history lives with you instead of becoming a server-side movement log.

  5. 5

    Someone discovers your card.

    You control what and when they learn.

    You can hide your age, general area, school, bio, music, and social handles from non-friends, then preview their exact view. Nearby Suggestions is opt-in.

    You can also delay the notification shown on another person's device, from a minute to a full day, or turn it off. That helps avoid announcing the exact moment and place where they crossed paths with you.

    Effect: a bump does not automatically reveal every profile detail or immediately tell a stranger where you just were.

  6. 6

    Extra care is needed for younger users.

    Age changes what can be shared.

    weBump requires users to be at least 13. For anyone under 18, age and school are always hidden from non-friends. The app disables those controls, and the server independently refuses to publish those fields to strangers.

    Effect: changing a switch in the app or sending a modified request cannot bypass the under-18 age and school protection.

  7. 7

    Something feels wrong.

    You can stop the interaction.

    Blocking removes the person from your bumps, ends friendship connections and pending requests, and prevents future profile resolution in either direction. Reporting sends a snapshot for review so later profile edits cannot erase what was reported.

    At any time, you can turn nearby bumps off, clear local receipts, or use Start Over to delete the installation, profile, relationships, rolling IDs, and push tokens tied to it. Safety reports are retained to help prevent abuse and ban evasion.

    Effect: discovery is reversible, and safety actions continue to work after the original rolling ID changes.

what about location?

Bluetooth bumps do not use GPS.

The optional local activity feature can use your current coordinates once to find a broad area. The server immediately converts them into a coarse 0.1-degree grid bucket, roughly 11 km north-to-south, and stores the bucket rather than your precise latitude and longitude.

the honest limit

Safer does not mean invisible.

Any active Bluetooth service can reveal that some compatible device is nearby. Rolling IDs are designed to limit long-term linkability and prevent a broadcast value from acting like a permanent name tag; they cannot make radio activity undetectable or defeat every sophisticated tracking technique.

That is why weBump layers temporary IDs with authenticated lookup, short retention, local history, field-level privacy, notification delay, minor protections, and block/report tools. No single safeguard carries the whole job.

The short version

No permanent Bluetooth name tag

Rolling IDs change every 15 minutes.

No central bump history

Encounter receipts stay on your device.

No automatic full-profile reveal

You choose what non-friends can see.

No exact-location database

Optional activity data is saved as a coarse area.