Threat Model & Anonymity Guide
What Hoppr protects, what it does not, and how to build a real privacy stack.
No communication system, anywhere, is 100 percent anonymous against every threat. Anyone who tells you otherwise is selling something. This page is the honest version.
TL;DR
- Message content. Strong. Mathematically unreadable by anyone except the two ends of a direct message.
- Physical presence. Weak over Bluetooth. A radio sniffer within roughly ten metres can see that your device exists.
- Metadata. Partial. Traffic patterns, peer identifiers, and geohash channel membership are observable to peers.
- Global anonymity. Only when the Nostr over Tor fallback is engaged, and only for network-layer observers. Your chat partner always sees what you send.
What Hoppr protects
Every direct message between two devices is wrapped in a Noise XX handshake producing forward-secret session keys. Actual message bytes are encrypted with ChaCha20-Poly1305 and authenticated. The cryptographic suite is the same family used by Signal, WireGuard, and modern TLS.
Concretely, this means:
- Relay devices along the mesh path see only ciphertext. They cannot decrypt the message even if they run modified Hoppr code.
- If your long-term identity key is later compromised, past conversations remain unrecoverable. Session keys were forward-secret.
- Bulk collection of encrypted traffic today cannot be decrypted retrospectively by improved algorithms. Breaking Curve25519 or ChaCha20-Poly1305 would require algorithmic breakthroughs that do not exist.
For mesh broadcasts and geohash public rooms the story is different. Those messages are signed but not encrypted. Anyone subscribed to the same geohash sees them in plain text. Treat them like an open radio channel.
What Hoppr does NOT protect
Be honest with yourself about the following. No amount of cryptography fixes these.
- Your physical location. Bluetooth Low Energy is a radio signal. A passive sniffer within range sees a device advertising. iOS randomises the MAC address, but the fact that a Hoppr device is present is visible.
- Traffic analysis. Packet volume, timing, TTL fields, and peer identifiers in headers can reveal communication patterns to well-resourced observers with multiple sniffers.
- Device fingerprinting. Radio transmitters have subtle physical characteristics that remain even with address randomisation. State-level attackers can sometimes correlate the same device across locations.
- Compromised endpoints. If spyware runs on your phone, it reads messages before encryption and after decryption. The same is true for the person you chat with. End-to-end encryption protects the wire, not the screen.
- Your chat partner. They can screenshot, forward, or simply remember what you wrote. No technology fixes consent.
- Peer identifiers. The first eight bytes of your public-key fingerprint appear in packet headers so the mesh knows where to route. Anyone observing the mesh can link your identifier to behaviour patterns over time.
- Presence announcements. Joining a geohash channel posts a presence heartbeat. Relay operators know you are online in that channel, even if they cannot read your DMs.
Threat matrix
- Casual snooper nearby
- Cannot read messages. Can see a Hoppr device exists.
- Local LAN/ISP
- Irrelevant for mesh. For Nostr fallback they see Tor traffic only.
- Nostr relay operator
- Sees encrypted gift-wrap. Does not learn sender, recipient content, or IP (through Tor).
- Tor exit or global passive adversary
- Traffic analysis possible with sufficient resources. Content stays encrypted.
- Someone with a BLE sniffer in a city
- Can triangulate device presence. Cannot read content.
- Your chat partner
- Sees everything you send. Full stop.
- Malware on your device
- Defeats all encryption. Reads messages on screen.
- Physical device seizure
- If unlocked, complete compromise. If locked, depends on iOS version and attacker capability.
- Future quantum computer
- Would break Curve25519 if and when it becomes practical. Current estimates: 10 to 20 years, possibly never. Not a short-term worry.
Channels explained
Hoppr has two kinds of public channels, plus private direct messages. These are often confused. The difference matters for your privacy.
- Mesh channel (
#mesh) - Local Bluetooth LE broadcast. No internet. Up to seven hops. Anyone in radio range sees the signed cleartext.
- Geohash channel (
#u1,#u33db, ...) - Public Nostr events routed over Tor. Global reach. Anyone on the internet subscribed to that geohash sees the signed cleartext.
- Direct message (
@nickname) - End-to-end encrypted via Noise XX. Travels over mesh when the peer is nearby, over Nostr-over-Tor when they are not. Only the two ends read it.
Simple rule: public channels are an open radio. Only DMs are private. Do not say anything in a mesh or geohash channel that you would not say on a megaphone.
Are there Hoppr servers?
No. There is no Hoppr backend. There is no backend for the wider public mesh either. Hoppr builds on top of Nostr, which is a decentralised protocol similar in spirit to email. "Channels" are not hosted anywhere specific. They are a convention: every message in a geohash channel is tagged with a geohash value, and public Nostr relays forward it to anyone subscribed to that tag.
The relays Hoppr uses by default are independently operated by the Nostr community, not by us:
- relay.damus.io
- Operated by the Damus iOS client project.
- nos.lol
- Run by Mike Dilger.
- relay.primal.net
- Operated by the Primal.net team.
- offchain.pub
- Community relay.
- nostr21.com
- Community relay.
These are not ours. Think of them as public bulletin boards. We route through Tor so relay operators see only ciphertext and no IP addresses. If any relay disappears, the others continue to work. You can also point Hoppr at your own relay if you run one.
Where do names like "Region", "Block", or "Friesland" come from?
Two layers, computed entirely on your device:
The underlying identifier is a geohash. A geohash is a short text code that represents a rectangle on Earth. Your phone takes your GPS coordinates, computes the full geohash for your position, and then takes the first few characters to form rooms at different zoom levels:
- 2 chars (e.g.
u1) - Region. Covers several hundred kilometres. All of northern Europe fits in a handful of these.
- 4 chars (e.g.
u33d) - Province or large metropolitan area.
- 5 chars (e.g.
u33db) - City or neighbourhood.
- 6 chars (e.g.
u33dbc) - Block. A few streets.
- 7 chars (e.g.
u33dbcx) - Building. Roughly one address.
The human-readable label next to the code (for example "Friesland" or "Berlin" or "Region") is produced by Apple's CoreLocation framework doing reverse geocoding on your own device. It does not leave your phone. The geohash itself is what other users see on the wire, not the label.
This means the same geohash shows up with different human labels depending on the user's language settings. "Berlin" for one user might display as "BerlĂn" for a Spanish-language device. The underlying geohash is identical.
Shared namespace with other apps
Because Hoppr speaks standard Nostr for these channels, it shares the public channel namespace with any other compatible open-source mesh messenger that follows the same convention. You may see messages in a channel from users of another client, and they may see yours. Your DMs remain end-to-end encrypted regardless. Only the public channels cross app boundaries.
Hoppr-native channels
Hoppr operates its own encrypted geohash channels by default. When you enable Include public mesh in Settings, your app also relays messages into the wider public geohash ecosystem so you can reach users running compatible open-source mesh messengers. Public channel traffic is visible to all participants in that geohash, that is the nature of a public room. If you turn the setting off, you continue to see and be seen by other Hoppr users on the native channels; you simply stop exchanging messages with the wider public mesh.
Who Hoppr is for
Hoppr is well suited for people who need one or more of the following:
- Communication during internet blackouts, protests, disasters, or restrictive regimes where cellular and Wi-Fi are unavailable or monitored.
- Local coordination at festivals, remote hikes, conferences, or any dense gathering where infrastructure is overloaded.
- A messenger that never touches a centralised server and never asks for a phone number.
- Short-range private conversations with verified contacts where the other side of the room is the adversary, not a nation state.
Hoppr is not sufficient on its own for:
- Whistleblowing against a state-level adversary. You need SecureDrop or equivalent.
- Hiding that you communicate with a specific person at a specific time. Traffic analysis will eventually correlate.
- Any scenario where your device may be physically seized and you have not rehearsed a panic wipe.
Building a realistic anonymity stack
Three tiers for three threat levels. Pick the highest one that matches your actual risk. Do not over-engineer: complexity is itself an attack surface.
Tier 1. Casual privacy
For anyone who does not want their mesh conversations readable by curious bystanders, parents, roommates, or Wi-Fi operators at a coffee shop.
- iPhone or Mac with Hoppr installed from the App Store
- Cloudflare 1.1.1.1 app enabled for global DNS-over-HTTPS
- Screen lock with a strong passcode, not just a fingerprint
- Verify contacts via QR before trusting them
- Use the panic-wipe gesture if the device is ever out of your hands
Tier 2. Journalist or activist
For people who might be profiled, tracked, or whose sources need deniable contact.
- Primary chat device: a dedicated iPhone, purchased with cash, not linked to your personal Apple ID. Use an anonymous Apple ID created over Tor if possible.
- SIM strategy: no SIM at all, or a prepaid SIM registered in another name where legal. Rely on Wi-Fi for Tor-backed Nostr when out of mesh range.
- Identity rotation: every few months, run Hoppr's "Start over with new identity" to generate fresh keys. Share the new QR with your verified contacts.
- Faraday bag for transport. Turning a phone off is not the same as making it radio-silent.
- Note-taking and drafts on a separate air-gapped device (old iPad with no SIM, Wi-Fi off). Never draft sensitive content on the phone that advertises BLE.
- Paper backup of your fingerprint hash, stored somewhere you trust. If a contact later receives a message claiming to be from you and the fingerprint changed without warning, suspect MITM.
- Signal as a secondary channel for contacts who are not on Hoppr. Never use SMS.
Tier 3. High-risk source or dissident
For the threat model where a state actor is the adversary. Hoppr is one layer here, not the whole plan.
- Everyday phone: GrapheneOS on a Google Pixel, Wi-Fi only, no Google account, full-disk encryption, automatic reboot after 72 hours. This is the most-studied privacy phone option in 2026.
- Hoppr on GrapheneOS once the Android port ships. Until then: a second iPhone purchased in cash, used only for Hoppr, always in aeroplane mode except when actively mesh-chatting.
- Laptop: Tails OS running from a USB stick on any clean machine. All sensitive drafting, research, and Tor browsing happens there. Nothing is persisted.
- Contact exchange: in-person only, fingerprint verified by QR scan, with the fingerprint also written on paper. Never accept a new contact remotely.
- Data separation: sensitive notes on an air-gapped device, transferred only by QR-code photos if needed. No cloud. No iCloud. No Google Drive. No email attachments.
- Panic plan: rehearse triple-tap panic wipe until it is muscle memory. Assume the phone will be taken.
- Operational security beats technical security. Who you talk to, when, from where, and what you say is a bigger vulnerability than any crypto flaw.
The question of which phone matters less than what you do with it. A jailbroken legacy BlackBerry is not a secure device in 2026. Modern BlackBerry-branded phones are Android and will run Hoppr like any Android. For maximum security in 2026, GrapheneOS on a Pixel is the community-audited choice.
Detecting a MITM
The single most important habit: verify fingerprints.
When you first chat with a new peer, Hoppr performs a Noise XX handshake. Without out-of-band verification, an attacker relaying the handshake can substitute their own keys and read everything. The remedy is simple: scan the other person's QR code, in person, and confirm the fingerprint matches on both devices.
If a contact's fingerprint ever changes without them telling you first, stop communicating through that channel. Verify out of band, via a different medium and ideally in person, before trusting the new key.
If your device is seized
- If you had a chance to trigger panic wipe: keys and messages are gone, identity can be regenerated. The attacker sees an empty app.
- If the device was locked and on a recent iOS version: full-disk encryption protects data at rest, but advanced forensic tools do exist. Assume content will be accessed within days to weeks.
- If the device was unlocked when taken: assume total compromise. Warn contacts immediately via another channel. Revoke your identity (generate a new one) so new messages cannot be read with the old key.
- Never log back into the seized device with any account linked to you.
Protocol identifiers
For researchers who want to verify Hoppr's behaviour on the wire, the native protocol exposes a dedicated BLE service UUID and a dedicated Nostr event kind and tag. These identify Hoppr's own channels and are distinct from the public-mesh interop path.
- BLE service (native)
F71E237E-B01A-414D-8082-5FE30926FA1F- BLE characteristic (native)
F72B86C8-B80A-466A-9B95-9097B042D989- Nostr ephemeral event kind
20100- Nostr presence event kind
20101- Nostr geohash tag
hg- Packet version byte
0x02
When Include public mesh is enabled in Settings, Hoppr additionally speaks the common identifiers used by the wider open geohash ecosystem so interop works. When it is disabled, only the native identifiers above are advertised and subscribed.
Responsible disclosure
If you discover a vulnerability in Hoppr, email security@hoppr.chat. We respond within three business days. The PGP key fingerprint is published in the app under Settings and in /.well-known/security.txt.