Case study 01 / 04
Mesh networking · 2026
ResQNet
Emergency communication beyond the internet.
- View source
- Live previewRequires a Vercel sign-in
- Type
- Mesh networking
- Year
- 2026
- Status
- Experimental research
- Core stack
- Java 21, Android, Nearby Connections
01Overview
Overview
An offline-first, self-healing emergency network. Nearby phones store, sign and relay SOS messages hop by hop, with no server, account or SIM anywhere on the emergency path.
Servers on the emergency path
Of graph-optimal delivery at 100 nodes
Automated tests across 7 suites
02The problem
Disasters take out the infrastructure everything else depends on: towers, backhaul and the internet itself. What usually survives is phone radios, batteries and people nearby. ResQNet asks whether that is enough to get a message through, and is honest about when it is not.
03The approach
Every handset runs the same mesh core: a router, a persistent SQLite queue and a signing identity. Phones link over Bluetooth and Wi-Fi Direct through Google Nearby Connections, and a message moves by store and forward until it reaches its recipient or runs out of lifetime. An optional Spring Boot gateway and a React command centre receive metadata when connectivity exists, but they are never on the emergency path.
04How it works
How a message crosses the mesh
- 01
Sign
Phone A composes an SOS and signs the envelope with ECDSA P-256. Its device ID is derived from its own public key.
- 02
Persist, then hand off
Relay B writes the envelope to SQLite before acknowledging it, so the queue survives the process dying.
- 03
Relay with rules
Split horizon, a bounded hop budget and duplicate suppression keep the message moving forward without flooding the mesh.
- 04
Verify and acknowledge
Phone C verifies the origin signature, then sends an application-level ACK back through B to A.
05Under the hood
Under the hood
01
Identity is a key, not an account
Every envelope is signed. Keys are exchanged out of band with an in-person fingerprint check, and unknown devices stay UNVERIFIED.
02
End-to-end encrypted when directed
Directed messages use HPKE with X25519, HKDF-SHA256 and AES-256-GCM, so relays carry them without reading them. Public SOS broadcasts stay unencrypted on purpose.
03
Delivery states that never lie
SENT_TO_PEER and ACKNOWLEDGED are never merged. One radio hop reads as handed to a nearby device, and anything undelivered is reported as expired.
04
Offline triage
An on-device keyword classifier assigns a category and severity to every message before it is transmitted.
06Results
Simulated delivery, directed messages
Hop budget, not mesh size, decides whether a message crosses. What limits delivery is the graph, not the router.
| Nodes | 4-hop budget | 32-hop budget |
|---|---|---|
| 10 | 90% | 90% |
| 50 | 15% | 90% |
| 100 | 24% | 88% |
| 500 | 2.4% | 21.6% |
Results from a seed-deterministic, discrete-event simulator that runs the real MeshRouter. They are simulation results, not field measurements.
07Honest limits
Honest limits
- 01Three-device multi-hop routing has not yet been verified on physical hardware.
- 02Real radio range and battery behaviour are still unknown.
- 03Doze mode and aggressive task killers can suspend the background service.
- 04HPKE key rotation is not part of v1.
- 05Next up: physical multi-hop validation, challenge-response identity binding and key rotation.
08Stack
Technology stack
- Java 21
- Android
- Nearby Connections
- SQLite
- Spring Boot 3.5
- PostgreSQL
- Flyway
- React 18
- TypeScript
- Zustand
- WebSockets
- GitHub Actions