Offline Mesh Communication

The Inspiration

In Kashmir, internet shutdowns have lasted months. In Manipur in 2023, the blackout ran over 200 days. In Rajasthan, services were cut during protests with no warning.

We kept asking one question: what do people actually do when the internet is gone?

They walk to their neighbours. They shout across streets. They move — and through movement, information travels.

That was the seed. What if the phone in your pocket could do what you were already doing on foot, but faster and further?

What We Built

JanVaani (जनवाणी — "Voice of the People") is an offline-first progressive web app that lets civilians share and relay critical alerts during a complete network blackout. No internet. No cell towers. No server. Anywhere.

Information spreads the way rumours do — person to person — except cryptographically signed, time-stamped, and hop-counted.

The system has three transport layers depending on what is physically available:

Layer	Mechanism	Range
Same shelter	BroadcastChannel (browser tabs)	Instant
Nearby cluster	WebRTC over a local hotspot	~50 m
Physical handoff	QR codes and printed posters	1 m

An alert on Device A propagates to B, then to C — each hop recorded, each signature verifiable, with no central authority anywhere.

How We Built It

We started with the hardest constraint first: zero internet, zero server, zero infrastructure. That ruled out WebSockets, any cloud backend, and forced us to treat the browser as the entire stack.

The gossip protocol is the core. When two devices connect, they exchange hash lists of alerts they hold. Each side computes the diff and sends only what the other is missing — sorted by priority, emergencies first. Emergency alerts get maxHops = 50 and a 4-day TTL. Regular alerts get maxHops = 10 and a 2-day TTL. Once an alert exceeds its hop limit it stops propagating — natural decay with no coordinator.

QR as a physical network layer. For truly air-gapped transfer, we built animated multi-frame QR codes. Large payloads get compressed with pako (deflate) and chunked across frames that animate like a GIF. A nearby phone scans them in sequence and reassembles the bundle. The same mechanism bootstraps WebRTC — the SDP handshake travels over QR instead of a signaling server, so WebRTC itself requires zero internet infrastructure.

Cryptographic signing. Every alert carries a detached Ed25519 signature from an ephemeral keypair stored only in localStorage. The public key travels with the alert so any recipient can verify it. The confidence badge shows Signed XXXX-XXXX — the sender's key fingerprint. No account. No login. No persistent identity. One tap — panic wipe — deletes everything.

BroadcastChannel for demo reliability. We added a second transport that connects all browser tabs on the same device instantly with zero setup. We wrapped it in a fake RTCDataChannel-compatible interface so the existing gossip protocol runs over it without any changes. Open three tabs, label them A, B, C — an alert propagates with real hop counting in under two seconds. No hotspot, no QR, no failure modes.

What We Learned

The hardest problem in offline networking is the bootstrap — getting two devices talking when there is no shared infrastructure at all. QR-scanned SDP is inelegant but it works with zero infrastructure and zero battery cost.

Cryptography adds honesty to a gossip network. Without signatures, any relay could forge an alert. With Ed25519, you can verify origin without knowing who that person is. That is enough trust for a crisis.

The deeper lesson: the human is the network. Delay-tolerant networking calls this store-carry-forward. A node stores data, carries it through physical space, and forwards it when it meets another node. JanVaani just formalises what people naturally do in a blackout.

Challenges

WebRTC without a signaling server took the most time. Standard WebRTC assumes both peers can reach a server to exchange SDP. We replaced that layer entirely with QR codes — compressing, chunking, animating, and reassembling SDP payloads across camera scans.

BLE advertising was explored as a passive broadcast channel. The physics killed it — a BLE advertisement has 31 bytes of usable payload. A single compressed alert is 200+ bytes minimum. BLE can carry a beacon, not a message. We shelved it.

HTTPS on a local network — camera access and service workers both require HTTPS, but there is no certificate authority in an offline environment. Every demo device needs to manually accept a self-signed cert warning once before the camera works.