Chirp

Alert on Phone
Receiver picking a suitable language
Problem Statement
Broadcaster choosing the kind of alert
Broadcaster choosing the affected zone to alert
Broadcaster choosing an instruction
Help requests in the queue
Block diagram of the project
Chirp Poster
Helpline implemented using Retell AI

Inspiration

In January 2025, as wildfires swept Los Angeles, two things went wrong at once: cell towers went down in the burn zones, and a mistaken evacuation alert lit up phones across the entire county. Alerts failed people in three ways: no network, English only, and everyone at once.

We kept picturing one person: Mrs. Kim, at the Coliseum for LA28. She reads Korean. In an emergency, her phone is either silent or shouting the wrong thing, in the wrong language, to the wrong block. The hackathon asked for the gentlest response that still works. For alerts, we think that's sound.

What it does

CHIRP turns any loudspeaker into a signed, offline, multilingual alert channel.

A responder picks an alert on their phone or laptop, previews it in every language, and taps Approve. A person approves every alert; nothing is sent automatically.
The console plays a few-second chirp through any speaker: a stadium PA, a fire truck's loudspeaker, a Bluetooth speaker.
Every phone within earshot decodes it with no cell signal or Wi-Fi, verifies the digital signature, and shows the alert in its owner's language.

Fakes are flagged: an unsigned chirp shows as UNVERIFIED and never sounds the alarm.
Replays expire: recorded alerts are rejected after their validity window.
People can answer back: "I need help" is sent the same way, by sound, into a ranked help queue that a named person must close.
Official alerts plug in: the console imports CAP/IPAWS alerts and maps them to signed codes.

Two lives, one tool: on ordinary days, multilingual gate and transit announcements for LA28 crowds. In a crisis, an alert that still works when towers fail, and reaches only the block that has to move.

How we built it

Data over sound: ggwave encodes data as audible tones. We use only audible protocols, since ultrasonic tones don't survive loudspeakers.
Trust: every alert is signed with Ed25519 (TweetNaCl.js) and verified on the phone against trusted public keys.
Tiny messages: we never send sentences. An alert is an 11-byte code (type, detail, zone, expiry, message ID) plus a 64-byte signature:

$$ 11 + 64 = 75 \text{ bytes} \;\xrightarrow{\text{base64}}\; 100 \text{ characters} \;\approx\; 6.8\,\text{s of audio} $$

Every language, no AI at receive time: each phone renders the code from a pre-written phrasebook in 9 languages, so translations can be checked by people ahead of time.
Offline-first: plain HTML and JavaScript with a service worker. Load the page once, then it works in airplane mode.
Safety rails: a 60-second repeat cooldown, typed confirmation for wide zones, a 12-hour validity cap, and a help queue where nothing is auto-dismissed.
Help server: a Node server receives help requests when any connection returns, plus a Retell voice line for people without smartphones.

Challenges we ran into

Binary data got corrupted. ggwave's JavaScript encoder treats input as text, so we switched to base64.
Browsers "cleaned up" our signal. Echo cancellation and noise suppression filtered out the chirp as noise until we turned them off.
Fitting a signature into seconds of sound. A cryptographic signature is larger than the message itself. Keeping alerts to fixed codes kept the whole thing to about 100 characters.
Alerting both Android and iPhone. The two platforms handle web alerts differently: iPhone Safari can't vibrate, both require a tap before audio or the microphone can start, and each one's mic processing behaves differently. We designed the alert to work on both: a full-screen card, a tone and a visual flash everywhere, plus vibration where Android supports it. Sounding through silent mode or listening in the background would need a native app (and Apple's Critical Alerts permission), so that's on our roadmap.
Phone rules: the microphone requires HTTPS, and screens must stay awake to keep listening.
Honesty about limits: phones in pockets can't hear a chirp unless the receiver is open. That shaped our roadmap: an installable app with an "alert mode," plus shelter screens.

Accomplishments that we're proud of

An end-to-end signed, offline, multilingual alert, from a responder's tap to a phone's screen
A trust model where fakes never buzz and every help request reaches a person
A tool with two lives: useful every event day, and ready when the network fails

What we learned

Trust matters as much as delivery. An alert channel anyone can spoof is worse than none.
The gentlest response is often the most local one. Sound is hyperlocal by physics.
Translation belongs before the emergency, written and reviewed by people, not generated on the fly.

What's next for Chirp

An installable app with alert mode (background listening during events and fire-weather days)
Low-cost shelter receivers for buses, shelters and senior centers, for people without smartphones
Native-speaker review of every language, and more languages
Field tests through real PA systems, and a pilot with a venue or LA Metro
Working alongside Wireless Emergency Alerts, not replacing them