Moby started with news of floods and landslides in Nepal, and with a question that stuck with us: what happens when someone nearby can see the danger, but the people who need to know can't get the warning?
On a trekking route or in a remote valley, the signal is weak and the towers are often the first thing to go. Travellers have it worst. The warning comes from an agency they've never heard of, in a language they can't read. And getting an alert is only half the job. People also need to know who issued it, how recent it is, whether anyone has confirmed it, and what to do right now.
I wanted official monitoring data and what people see on the ground to work together, with AI explaining things in plain words and code deciding what counts as confirmed. That's Moby: an Android app for early warnings that people can understand, trust, and still use when the signal drops.
What it does
- Official alerts from around the world, near you. Moby watches national weather services, earthquake and tsunami centres, cyclone centres and CAP feeds (NWS, USGS, EMSC, GDACS, NASA EONET, PTWC, NHC, JTWC, JMA, Nepal's BIPAD, MeteoAlarm and more). You see only the ones within the radius you choose.
- Warnings you can understand. Non-English warnings are translated, and every official alert gets a short What this means for you: 2–3 plain sentences and up to three actions, in the phone's language. The agency's original text is always one tap away.
- Ask Moby. A safety assistant that answers with numbered citations from official alerts, saved guidance and official government websites. When its sources don't cover a question, it says it can't answer instead of guessing.
- Before you go. Pick a destination or a multi-stop route (say Lukla → Phakding → Namche Bazaar), or long-press the map. Moby explains the alerts and reports along the way, with sources, and saves an offline pack with local emergency numbers.
- Situation briefs and "What changed". Open an event and Moby writes a sourced brief: official warnings, what people nearby reported, relevant official sites and news, what's still unknown, and what changed since the last brief.
- Community reports, clearly labelled. Anyone can report a hazard. Reports of the same hazard are grouped into one event, counting distinct people. They're always shown as Unverified with that count, and only a match with an official agency makes something Confirmed. Each user chooses whether to hear about community reports: off, only when 2+ people agree (the default), or all.
- Works offline. Last-known alerts, safety guidance cards (with source and update date) and emergency numbers stay on the phone. On phones with enough memory, Ask Moby keeps answering with no signal, using NVIDIA Nemotron 3 Nano 4B on the device and only the guidance saved there.
- Push notifications for alerts near you and in saved places, filtered by hazard and severity.
- Route check. Pick where you're going and Moby checks whether the usual route crosses an official warning area or a community report, shows each one on the map, and finds a way around when there is one. It never calls a route safe: only that it crosses no hazard Moby knows about, and what that leaves out.
- Emergency mode. When you're inside an official warning area, Moby opens a do-this-now screen. I need help shows your coordinates large enough to read out over the phone.
- Works over Bluetooth when there's no signal. Turn on nearby relay in Settings and reports, alerts and SOS calls hop between Moby phones until one of them has signal. I need help sends an SOS to nearby phones, and I'm safe now tells them you're OK.
- Privacy controls. Export or delete your data and choose what you share. Ask Moby questions aren't stored.
Moby complements official warning systems. It doesn't replace official alerts, emergency services, or instructions from local authorities.
How we built it
Official feeds. A poller fetches each feed with conditional requests, normalises everything into one event schema, removes duplicates across networks and links each update to the earlier versions. Non-English warnings are translated as they come in.
Community reports → events (LangGraph). A report goes through a LangGraph worker:
structured_report → fuse → score → save → draft_alert. Nemotron Nano turns the reporter's free-text note
into structured fields. The rest is deterministic. PostGIS puts the same hazard within 1 km and 2 hours into
one event. Plain rules decide the tier and severity. The alert text comes from a template, and delivery adds
the trust label itself. The graph never pauses for a human: I decided not to make warnings wait for a
reviewer I couldn't staff. Though it would be nice to collaborate with local authorities
Situation briefs (LangGraph + Ultra + Tavily). A second graph runs on a leased queue with a Postgres
checkpointer: gather_evidence → research → write_brief → check_brief → explain_changes → save_brief.
SQL gathers the official facts and the community evidence. Tavily searches official sites and news, using
queries built from structured fields and never from a reporter's note. Nemotron Ultra writes the brief.
Code checks every statement against its citations. A failed check gets one retry and then a repair step.
"What changed" is computed by a SQL diff, and Nemotron Super only puts it into words.
Guidance and offline. A Serverless Job uses Nemotron Ultra to write safety guidance cards from official pages (Ready.gov, NWS, national agencies). Every line must cite the line of the page it came from. The app syncs the cards for the US and the country you're in. With no signal, the on-device model ranks the saved cards (BM25), answers with a fixed JSON schema and runs the same grounding checks as the server. If the check fails, you see the cards themselves.
Route check. OpenRouteService gives the usual route. PostGIS finds the active hazards it touches: official warnings with a real area (NWS polygons or the union of their zones) and community reports as 500 m circles. If it touches any, ORS is asked again with those areas to avoid, and the new route is checked the same way, because ORS doesn't always manage it. Warnings too large to route around (whole counties) are named as such. No model is involved: it's geometry against official and reported data. Only the two points leave for ORS, with no account or device id.
Emergency mode and SOS. When the phone is inside an official warning area, the app opens a do-this-now screen. I need help shows your coordinates to read out and, with Bluetooth on, sends an SOS over the relay.
Bluetooth relay. A small Expo module in Kotlin advertises and scans 24-byte messages, with a seen-cache, hop limits and rate limits, so a report, an alert or an SOS can pass between nearby phones and upload when one of them gets signal. It keeps running in the background with a foreground service, survives Bluetooth restarts, and a report that fails to send is handed to nearby phones automatically. I tested it between real phones. It stays off until you turn it on, since it uses battery and needs Bluetooth permissions.
NVIDIA Nemotron on Nebius Token Factory
The first rule: models never decide whether something is confirmed or how urgent it is. Deterministic rules do. Every model output goes through a check before anyone sees it.
| Model | What it does in Moby | How it's kept honest |
|---|---|---|
Nemotron 3 Nano (nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B) |
Translates warnings when they arrive. Structures community report notes. Rewrites Ask Moby questions into generic search queries with no personal details. | A translation must keep every number in the original, or it's thrown away and the original is shown. |
Nemotron 3 Super (nvidia/nemotron-3-super-120b-a12b) |
What this means for you (also used in the push). Ask Moby answers. Translation into 17 phone languages. "What changed" wording. | No number that isn't in the source. The answer's words must come from the sources it cites. Otherwise it abstains or the explanation is withheld. |
Nemotron 3 Ultra (nvidia/Nemotron-3-Ultra-550b-a55b) |
Guidance cards. Before you go. Situation briefs. | Each statement must cite its sources, and its numbers, place names and hazards must appear in them, or the statement is dropped. |
| Nemotron 3 Nano 4B (on the phone, GGUF via llama.rn) | Ask Moby offline, from the saved guidance only. | Same grounding checks, ported to TypeScript. If no saved card matches, the model never runs. |
| Qwen3-Embedding-8B | Retrieval for Ask Moby and event embeddings (pgvector). | Similarity cut-offs measured on real questions. |
I use Nano for high-volume, fast work, Super for what people read interactively, and Ultra for the slow,
careful work. One module (moby/llm.py) decides which model each feature uses. Every paid call has a daily cap in order to keep costs to $50 a month. Past the cap, features fall back to the official text instead of spending more.
Stack
- App: Expo / React Native (Android), MapLibre, Firebase Auth and Firestore, FCM, App Check, llama.rn.
- Backend: Python, FastAPI, LangGraph and LangChain, psycopg, LangSmith tracing.
- Data: Postgres 17 with PostGIS and pgvector.
- Nebius AI Cloud: Token Factory (OpenAI-compatible API), a Serverless Endpoint running the API, database, poller, brief worker and push delivery, Serverless Jobs (embeddings, guidance, backups), MysteryBox, Object Storage and Container Registry.
- Search: Tavily, limited to each country's official government domains for Ask Moby.
- Routing: OpenRouteService for the route check and place search.
Challenges we ran into
Deciding what the AI is allowed to decide. Early on we planned a model-driven event-matching agent and a human approval step before anything went public. Both caused trouble. The agent made "is this the same event?" hard to predict. The approval step meant warnings would wait for a reviewer that a one-person project can't staff. We replaced them with deterministic matching (distance, time and distinct reporters) and made trust visible instead: Unverified vs Confirmed, how many people reported, and a "reports disagree" warning.
Keeping long outputs grounded. Ultra writes rich briefs and trip explanations, and at first our checks were both too strict and too loose. They dropped correct statements (month names, hazard word forms) and let vague ones through. We tuned them on real Ultra runs: every rejected statement is logged, there's one retry and then a repair step, and web sources must mention the place to count.
A model on the phone. Running Nemotron Nano 4B offline meant a 2.8 GB download that can pause and resume, reasoning turned off in the chat template (it would take minutes on a phone), JSON-schema output, and only offering it on phones with enough memory. Everyone else keeps the guidance cards, which always work offline.
Bluetooth. Nearby-device discovery, Android permissions, background limits and brief contact between phones all affect whether a message gets through. React Native libraries can't advertise reliably, so we wrote our own Kotlin module. Forwarding a report must never look like several people confirmed it, so the relay keeps the original reporter's identity and drops duplicates. We got it working on emulators first, then tested it between real phones.
Never calling a route safe. A route check that finds nothing is easy to read as an all-clear. Moby only knows about the hazards in its feeds, so the answer says "crosses no hazard Moby knows about" and lists what that leaves out. Routing around a warning was harder than it sounds: some warnings cover whole counties, and ORS sometimes returns a "way around" that still crosses, so every alternative is checked again.
Learning LangGraph for the first time. I had to learn the app's flow into explicit state, conditional routing, retries, a leased work queue and a checkpointer, and decide node by node what needs a model and what should stay plain code.
Time. Why is life so busy during a hackathon??
Accomplishments that we're proud of
- A rumour never looks like a government warning, anywhere in the app.
- Every AI output is checked against its sources before anyone sees it, and the app says "I don't know" rather than guessing.
- Moby never shows a false all-clear. If it can't check, it says so.
Whats Next
- Bluetooth relay at scale: test with more phones at once, across more devices and Android versions, and in the field on a real trekking route.
- Local partners: rangers, guides and officials who can confirm or take down reports in their area.
- More regions, done carefully: add local official sources and guidance before claiming coverage.
- iOS and smaller on-device models for phones with less memory.
- Scale: split the single endpoint into queues and independent workers, and measure latency and cost per alert as usage grows.
- A community that rewards quality, not report volume or sensational claims.
- More Evals
Built With
- apns
- fastapi
- firebase-cloud-messaging
- langchain
- langgraph
- nebius-token-factory
- noaa
- nvidia-nemotron
- pgvector
- postgis
- postgresql
- python
- react-native
- usgs


Log in or sign up for Devpost to join the conversation.