-
-
Dashboard before run simulation
-
After run simulation
-
docs and quick start
-
ml training
-
dashboard with features
Inspiration
During an emergency, telling someone to "get online" isn't always an option.
A collapsed tower, damaged infrastructure, power outage, or overloaded network can turn a smartphone into an isolated device at exactly the moment communication matters most.
But connectivity is only half of the problem.
Imagine a responder receiving hundreds of messages:
"Need help."
"Water is entering our building."
"My father is injured and cannot walk."
"We are trapped on the second floor."
Every message matters. But they cannot all receive the same response at the same time.
That led us to a two-part approach:
First, make the message resilient to infrastructure failure.
Then, make the incoming information easier for a human responder to prioritize.
That's what Mesh-Net is built to explore.
What it does
Mesh-Net SOS Relay is an offline-first disaster communication prototype designed to keep emergency messages moving when conventional connectivity is unreliable.
Instead of requiring every device to connect directly to a central server, the system allows nearby nodes to relay SOS messages across multiple hops until they reach a gateway.
Once an SOS reaches the gateway, a locally trained ML classifier analyzes the message using TF-IDF features and provides an initial prediction of its category, severity, and confidence.
The results are then streamed to a real-time responder dashboard, giving responders a clearer view of incoming emergencies and network activity.
Person sends SOS
↓
Nearby Node
↓
Multi-hop Mesh Relay
↓
Gateway
↓
Trained Local ML Model
↓
Category + Severity + Confidence
↓
Responder Dashboard
Keep the message moving when infrastructure is unreliable.
Use local intelligence to help make sense of the messages that arrive.
How we built it
Mesh-Net was built as a modular, end-to-end prototype combining mesh networking, a trained local ML model, a FastAPI backend, and a real-time web interface.
1. Mesh Communication
The networking layer is implemented in src/node.py and src/network.py.
SOS messages are introduced into the simulated network and forwarded between neighboring nodes using multi-hop flooding. Each message has a TTL (Time To Live) to limit propagation, while simulated transmission loss models unreliable communication.
2. Machine Learning
Once an SOS reaches the gateway, it is passed to the ML pipeline in src/classifier.py.
We trained a lightweight machine-learning classifier on a labeled dataset of SOS messages using TF-IDF text features. The trained model predicts the message's category, severity, and confidence.
The model runs locally during inference, so the system does not depend on an external AI API to process incoming messages.
3. Backend & Real-Time Communication
The backend is built with FastAPI in backend/app.py.
WebSockets stream network events and ML results to the frontend in real time, allowing the dashboard to visualize an SOS as it moves through the network and reaches the gateway.
4. Responder Dashboard
The frontend provides a live view of the simulated mesh network, relay activity, incoming SOS messages, and ML triage results.
The complete architecture is:
SOS Message
↓
Mesh Network
↓
Multi-hop Relay
↓
Gateway
↓
TF-IDF Features
↓
Trained ML Classifier
↓
Category / Severity / Confidence
↓
Responder Dashboard
The project is also containerized with Docker for consistent setup and deployment.
The key engineering goal was integration: an SOS must first survive the communication layer before the trained ML model can help make sense of it.
Challenges we ran into
Designing for an unreliable network
The biggest challenge was avoiding the assumption that every message would reach its destination.
A simple simulation could treat delivery as guaranteed, but that would not represent the conditions we wanted to explore. We introduced simulated transmission loss so that delivery depends on the state of the network.
Controlling message propagation
Multi-hop forwarding creates another problem: a message can potentially continue spreading through many nodes.
We addressed this using TTL-based propagation limits, giving every message a bounded lifetime and preventing uncontrolled network-wide propagation.
Keeping the ML layer offline
Using a hosted AI API would have made classification easier, but it would introduce an external connectivity dependency.
Since the core problem is communication failure, we wanted the intelligence layer to remain locally available. This led us to use a lightweight TF-IDF + classifier pipeline that can perform inference without an external AI service.
Making ML useful rather than decorative
Another challenge was deciding what role machine learning should actually play.
Instead of using ML simply to label messages, we designed it as a triage signal that provides category, severity, and confidence to help organize incoming SOS messages.
The model is not treated as the final decision-maker. Confidence is exposed so uncertain predictions can remain subject to human review.
Connecting everything into one system
The final challenge was integration.
The mesh layer, ML classifier, FastAPI backend, WebSocket stream, and frontend dashboard all needed to work together as one pipeline.
An SOS should not just exist in the network simulation or the ML model independently. It needs to travel through the network, reach the gateway, be processed, and then appear in the responder interface.
That end-to-end integration was one of the most important engineering challenges of the project.
Accomplishments that we're proud of
We are most proud of turning the idea into a working end-to-end prototype rather than building isolated components.
The system connects multiple layers into one flow:
SOS Message → Multi-hop Mesh → Gateway → Local ML → Real-time Triage Dashboard
We successfully implemented:
- Multi-hop SOS message propagation across simulated nodes
- TTL-based control of message propagation
- Simulated transmission loss for unreliable network conditions
- A locally trained TF-IDF + classifier ML pipeline
- Category, severity, and confidence predictions
- FastAPI backend with WebSocket-based real-time updates
- A live dashboard that visualizes network activity and incoming triage results
- Docker support for running the complete prototype consistently
What makes the project meaningful to us is the integration:
The ML layer only becomes useful after the communication layer gets the message through.
What we learned
The biggest lesson was that designing for failure changes the architecture from the beginning.
In most applications, connectivity is an assumption. In Mesh-Net, connectivity is the problem we are designing around.
Building the project taught us how networking constraints such as packet loss, multi-hop propagation, and TTL limits affect system design. We also learned that an ML model becomes much more valuable when it has a clearly defined role rather than being added simply because a project needs "AI."
Keeping inference local also changed how we approached the ML pipeline. Instead of depending on a large remote model or external API, we focused on a lightweight approach that fits the project's offline-first constraint.
Most importantly, we learned that building a resilient system is not about making every component perfect. It is about making the entire pipeline continue to provide useful functionality when individual assumptions fail.
What's next for Mesh-Net SOS Relay System
The current implementation is a simulation and proof of concept. Our next goal is to move from simulated nodes toward real edge devices and evaluate the system under real-world constraints.
Network
- Real device-to-device communication
- Store-and-forward messaging
- More efficient routing algorithms
- GPS-aware node discovery
- Battery-aware routing
- Real measurements of latency, hop count, packet loss, and delivery rate
Security
- End-to-end message encryption
- Node authentication
- Protection against malicious or spoofed messages
- Secure gateway communication
ML
- Larger and more representative SOS datasets
- Improved classification accuracy
- Better handling of ambiguous messages
- Compact models optimized for edge devices
- Confidence-aware triage and human review workflows
Hardware
We want to eventually test the concept on low-power devices and investigate how the mesh could operate when conventional cellular or internet connectivity is unavailable.
The long-term goal is to move from a controlled simulation toward a measurable, resilient communication system that can be tested under real-world constraints.
Today, Mesh-Net proves the concept in software. Next, we want to prove how far that concept can go outside the simulation.
We also intend to keep the project open source, so others can inspect, build on, test, and contribute to the system as it evolves.
Log in or sign up for Devpost to join the conversation.