How Inviz actually works.
A short, honest tour of the engineering for the technically curious - the mesh, the crypto, and the threat model. Inviz is built on a simple discipline: never claim a protection the code doesn't provide, and say plainly what is out of scope.
Architecture
The stack
Inviz is built as horizontal layers with one hard seam - the Transport interface - that isolates everything radio-specific from everything meaning-specific. Above the seam, the app thinks in messages and identities; below it, in Bluetooth realities like MTU limits and fragmentation.
The seam matters for privacy, not just tidiness: transport-level peer identifiers are ephemeral handles meaning "a neighbour reachable right now" and are never derived from your cryptographic identity or hardware address. A future second transport (e.g. Wi-Fi proximity) plugs in at the seam without touching routing, security, or UI.
Mesh
Routing: managed flooding
When you send a message, it doesn't follow a computed route - there is no router in the room. Instead it floods: every Inviz device that hears it passes it on once, until it reaches the recipient or runs out of hops.
- Duplicate suppression. Every packet carries a message ID; a seen-cache makes sure each device relays a given message once, so floods don't loop or echo.
- Bounded hops. Each relay decrements a TTL, capped at 7 hops - enough for realistic proximity chains, small enough to bound amplification.
- Store-and-forward. A message for someone temporarily out of range can be held (bounded by age and size) and handed over when they reappear. The mesh bridges time as well as distance.
- Relay fairness. A per-source rate limit stops any single device from monopolising the flood.
- Relays are content-blind. Routing reads only the envelope - sender, recipient, TTL. Encrypted payloads are forwarded as-is, unread.
Cryptography
Noise, not novelty
Direct messages are end-to-end encrypted with the Noise Protocol Framework - specifically Noise_XX_25519_ChaChaPoly_SHA256: X25519 key agreement, ChaCha20-Poly1305 authenticated encryption, SHA-256. No hand-rolled primitives, no custom state machines; the implementation is a vetted, widely-deployed library used through a single seam.
- Keys never leave your device. Your long-term identity key is generated on first launch and protected by the Android Keystore, hardware-backed where the device supports it.
- Mutual authentication + forward secrecy. Each session uses fresh ephemeral keys - compromising one session doesn't expose past or parallel ones.
- Trust on first use, verification in person. A first contact is authenticated to a key (TOFU) and marked unverified. Comparing a short safety number in person pins the contact's key; if a different key ever appears, the app shows it plainly.
- Broadcast is cleartext by design. The public channel is an open shout to everyone nearby, labelled unmistakably. The UI never presents it as private.
At rest: the local message store is encrypted with a Keystore-wrapped key, excluded from cloud backups (allowBackup=false), and a panic wipe destroys keys, contacts, and history irreversibly.
Power
Surviving Android
Continuous BLE scanning is the battery cost of a mesh, so Inviz trades discovery latency for power on an honest ladder - and tells you which mode it's in:
| Condition | Mode | Scanning |
|---|---|---|
| Charging | Active | Low-latency |
| On battery, screen on | Balanced | Balanced |
| On battery, screen off | Resting | Low-power |
| Battery 15% or lower | Resting | Low-power - survival over reach |
A foreground service keeps the mesh alive in the background, with a truthful notification reporting the live state and a Stop action. Some manufacturers add their own background-killers beyond stock Android; Inviz walks you to the right settings screen for your device rather than pretending the problem doesn't exist.
Threat model
Who we defend against
Inviz is designed against a ladder of adversaries, weakest to strongest:
| Adversary | Scope | Notes |
|---|---|---|
| Passive RF eavesdropper | In scope | Someone in Bluetooth range with a sniffer. The primary adversary - sees only ciphertext for DMs. |
| Active local attacker | In scope | Can connect, inject, replay, and attempt MITM at session setup. Defeated by Noise mutual auth + in-person verification. |
| Malicious mesh participant | In scope | A legitimate-looking relay. Cannot read or undetectably alter forwarded DMs; flooding abuse is rate-limited. |
| Device thief (locked device) | Partially | Encrypted store + Keystore-held keys + panic wipe. A live, unlocked device in an attacker's hands is out of scope. |
| Global passive adversary | Out of scope | Nation-state RF mapping at scale. We reduce the surface; we do not claim to defeat it. |
What we deliberately don't claim
Security products fail people when they overpromise. Inviz does not protect:
- That someone nearby is running a mesh. Bluetooth advertising is observable by design - to be discoverable, we must emit something.
- Traffic analysis. Relays necessarily see that a message passed through, and who connects to whom locally is partially observable at the RF layer, even though content is encrypted.
- Guaranteed delivery. Radio range, background kills, and interference are real. Delivery receipts report what actually happened rather than pretending a mesh is a cloud.
- A compromised operating system. No userland app defends against a rooted or backdoored OS.
Invariants
Non-negotiables
- No telemetry, no analytics, no silent network calls - ever. There is no server to phone home to, and there never will be.
- The UI never claims a message is encrypted when it is not, nor a contact verified when it is not.
- Transport identifiers stay decoupled from cryptographic identity, enforced structurally at the transport seam.
- Blocking is local and undetectable. Blocking someone drops everything they send before it reaches you, without leaking that they were blocked - indistinguishable from being out of range, so it can't be retaliated against.