NegibourNet

Inspiration

Cyclone Amphan hit West Bengal in May 2020 and knocked out almost half the state's cell towers in a single day. People in places like Basirhat, Gosaba, and Namkhana had no way to call for help for two to three days straight. Not because they didn't have phones, but because there was nothing left for those phones to connect to. Cyclone Yaas came back and did the same thing a year later. We started looking at the standard advice people get in these situations, call 100, use WhatsApp, hit SOS on Google Maps, and realized all of it depends on the same infrastructure that fails first. Satellite phones exist, LoRa mesh radios exist, but almost nobody stuck in a flood zone actually owns one. What people do have, even in the middle of a disaster, is a regular Android phone. So that's what we built around.

What it does

NeighbourNet turns any Android phone into a node in a mesh network that forms itself, no setup required. When someone hits SOS, their message (location, a short description, a timestamp) gets scored right away by an on-device AI model into one of four priority levels: CRITICAL, HIGH, MEDIUM, or LOW. All of this happens offline. From there the message hops from phone to phone over Bluetooth and Wi-Fi Direct, with each nearby device quietly relaying it forward in the background without anyone having to do anything. As soon as one phone in that chain picks up even a flicker of signal, it becomes a gateway and pushes the whole prioritized queue out. On the other side, relief coordinators get a live map with duplicates already filtered out, so they can send help to the most urgent cases first instead of waiting for the entire network to come back online.

How we built it

The mobile app runs on React Native with a Kotlin native module that wraps Google's Nearby Connections API (using the P2P_CLUSTER strategy) to handle the Bluetooth and Wi-Fi Direct mesh layer. A local SQLite queue keeps track of TTL, hop count, and sync status for every message. For triage, we fine-tuned distilbert-base-multilingual-cased for 4-class classification, exported it to ONNX, and applied INT8 dynamic quantization so it can run fully offline on a mid-range phone. There's also a keyword-based regex scorer as a backup in case the model fails to load. On the backend we're using FastAPI and Supabase (Postgres plus Realtime) for deduplication and ingestion. Gemini 1.5 Flash re-scores and summarizes each batch once it lands. Coordinators see everything through a Next.js 15 dashboard built with Leaflet and Grafana, giving them a live, color-coded view of the situation.

Challenges we ran into

Shrinking a multilingual model small enough to run on-device without losing accuracy on Bengali and transliterated Bengali turned out to be a lot harder than we expected. Full multilingual DistilBERT is heavier than a single-language model to begin with, so quantization alone wasn't enough, we had to keep going back and iterating on the compression pipeline. Bluetooth mesh behavior also isn't consistent across Android OEMs, which made peer discovery a lot less predictable to test than it looks in a single-device demo. On top of that, we spent real time fighting aggressive battery managers (Xiaomi especially) to keep the foreground service alive, and figuring out clean deduplication for cases where multiple gateways upload the same message at once.

Accomplishments that we're proud of

We got a working end-to-end pipeline inside the hackathon window: offline SOS creation, on-device triage, mesh relay, gateway sync, and a live coordinator dashboard, all connected. We're especially happy that multilingual triage actually works across English, Bengali, and transliterated Bengali, since that's the real mix of language victims in Bengal use day to day. We also managed to get past the "nobody opens a disaster app until disaster strikes" problem by designing NeighbourNet as something people would use daily, not just during an emergency, so the mesh is already active and trusted before anything goes wrong.

What we learned

The biggest thing we learned is that disaster tech has a hidden retention problem. An app people only open during a crisis is usually an app that's outdated, uninstalled, or unfamiliar exactly when it matters most. Framing NeighbourNet as everyday community infrastructure instead of just an emergency tool ended up mattering just as much as the mesh networking or the ML work. We also learned a lot about the practical limits of peer-to-peer mesh networking (range, OEM quirks, battery tradeoffs) and how genuinely hard it is to compress a multilingual transformer for edge deployment without losing the languages that actually matter for our users.

What's next for NeighbourNet

Next we want to build out the daily-use side that keeps the mesh alive between disasters: a neighborhood community board, an offline local directory, agricultural and government scheme notifications, and mesh-powered attendance or check-in tools for rural governance. On the technical side, we're planning iOS support, end-to-end encryption with device-level message signing, a LoRa-based extension for longer range in sparser rural areas, and two-way messaging so coordinators can talk back to victims, not just receive from them. Longer term we want to talk to NDRF and state disaster management authorities, NGOs, and telecom operators about getting NeighbourNet pre-installed and trusted before the next cyclone season hits.

Built With

• bluetooth
• fastapi
• google-nearby-connections
• grafana
• huggingface-transformers
• leaflet.js
• nextjs
• openstreetmap
• postgresql
• python
• react-native
• supabase
• typescript
• wifi-direct