Re — Communication for When the Internet Goes Dark

“An intentional disruption of internet or electronic communications, rendering them inaccessible or effectively unusable, for a specific population or within a location, often to exert control over the flow of information.”

Access Now, definition of an internet shutdown

Shutdowns are a deliberate instrument of state control — ordered during protests, conflict, and elections to sever coordination and make events impossible to verify. They produce silence, rumors, and filling the vacuum with unverified claims exactly when real information matters most.

The scale around the world

Those 32 shutdowns are the severe category — full-network shutdowns ordered by state authorities, including executive/local/state governments, judiciaries, law enforcements, and military. Affecting locations in more than 1 state, province, or region.

And the actual causes? Communal violence. Conflict. Elections. Information control. Political instability. Protests.

The human cost

Researchers call it digital deprivation. Beyond the emotional toll, shutdowns sever the practical channels people depend on when coordination matters the most.

Re extends the impact framework into the product flow and information architecture, and structure the system around these tiers, rather than treating all information as equally urgent or equally verified.

The mesh field

“This is super good in graphics and accessibility. This is fast and secure. But a problem: in my city no one has this app. This makes me alone in this app.”

Noghteha user review (lightly edited for clarity), AppBrain

That review reveals the constraint of mesh network in one sentence. A mesh only works if enough people nearby are running it, it's a threshold Re has to design around.

The first product direction addressed the psychological, social, and human-rights impact of internet shutdowns. Three pillars of survival infrastructure, with concepts like Calm Mode, Safety Pulse, and an Evidence Vault.

Reframed direction

Re became a fallback layer organized around three escalating emergency tiers — each surfacing only what's relevant to that moment, instead of one undifferentiated feed.

The cut features weren't bad ideas — they were the wrong *timescale*. Under Tier 1 conditions, nobody opens a breathing exercise. Reorganizing around escalating tiers turned a wish-list into a product with a spine.

Validating under stress

Re shapes the product's features, interactions, and interfaces to remain usable under server cognitive load during high-stress conditions. Tier 1 screens were run through simulated attention heat maps: does threat type, severity, and the report action pull the eye first or does someone scanning in a panic lose them in the noise?

Reaching the outside world

The people who most need a report from inside a blackout — family, responders, journalists — are on the internet; the people making it are on Bluetooth with none. A device with both radios can bridge the two. Crucially, bridging is off by default: running one reveals a device in the area has working internet, exactly what an adversary wants to find. It runs under a separate identity, so bridging never de-anonymizes the operator.

Rate-limiting the panic

Emergency reports are the most throttled channel in the app — one every twenty seconds — precisely because they matter most. A flood of false gunfire reports would saturate the mesh and destroy the corroboration count that makes the monitor worth trusting. Limits key on message content as well as sender, so rotating identities can't slip the same spam through.

* Adapted from the open-source project Bitchat — Re's technical foundation. † iOS doesn't expose classic Wi-Fi Direct; the peer-to-peer path uses Wi-Fi Aware (iOS 26), requiring iPhone 12 or later.

The process

1

Fork the foundation

A fork of the open-source Bitchat repository, inheriting its protocol foundation for transport, routing, and encryption.

2

Build with Claude Code

Features built iteratively with Claude Code as the primary implementation tool — generating, refactoring, and debugging against the codebase.

3

Review & QA in Xcode Simulator

Each change prototype-tested in the iOS simulator; UI details requiring hands-on judgment are fixed manually.

4

Design in Figma

Interface refinements were later explored in Figma before implementation, feeding learnings back into the next build cycle.

Early build

The first working build carried Bitchat's inherited terminal aesthetic — functional, but not built for someone scanning for a threat under pressure. It validated the data model and mesh sync before any visual design pass.

Both undersupply and oversupply fail — too few devices fragment the network, too many congest the radio. Phone-only mesh is unreliable without years of pre-crisis seeding. "In my city no one has this app" is that threshold, in human terms.

Future build – The ESP32 resilience layer

Cheap, always-on ESP32 relay nodes, hosted by community members on rooftops and inside hospitals, libraries, and shops. A new layer that act as persistent anchors, converting the network from opportunistic to anchored. This is part of the future build Re need to add to its infrastructure. Sized for downtown Toronto:

The limits are real: 2.4 GHz jamming can disable every node at once, fixed nodes can be mapped, and coverage clusters in higher-income neighbourhoods first. Conditional infrastructure — civic resilience augmentation, not a replacement telecom network.