Why Indian protesters reached for BitChat when the internet went dark

BitChat kept delivering its core value after the network it normally depended on stopped working. During July 2026 protests at Delhi's Jantar Mantar, mobile internet suspensions and signal jammers pushed demonstrators toward Bluetooth mesh messengers. BitChat moved messages between nearby phones without a SIM, account, mobile network, or central chat server.

The shutdown changed the transport

The protests were about alleged irregularities in national entrance examinations. When thousands of people gathered near Jantar Mantar, conventional messaging became unreliable around the protest site. ThePrint reported that demonstrators shifted to BitChat and Briar while mobile internet suspensions and jammers were in use.

BitChat does not make a phone independent of every system around it. It changes the immediate transport. Nearby devices discover one another over Bluetooth Low Energy, and each participating phone can relay a packet toward devices outside the sender's direct radio range. The current protocol starts packets with a maximum time-to-live of seven hops. Enough people in the same area can form a moving local network even when WhatsApp, mobile data, and web links fail.

The order targeted the code, not a message

On July 24, Jack Dorsey posted a two-page notice attributed to the Indian Cyber Crime Coordination Centre under the Ministry of Home Affairs. The notice was timestamped July 23 at 11:16 pm and told GitHub to remove three URLs within three hours: the iOS and macOS source repository, the Android source repository, and the Android releases page.

The notice described the same properties protesters found useful as a law-enforcement problem: account-free peer-to-peer communication, no central service provider, and continued operation during an internet shutdown. It cited risks including anonymous coordination and evasion of interception. The public pages did not identify a specific unlawful message in the repositories.

ThePrint could not independently authenticate the notice, and no public confirmation from I4C was available when it reported the story. The accurate claim is that Dorsey published an order attributed to I4C. The three-hour deadline and the listed URLs come from that document. GitHub's own policy says a complete government request must identify the illegal content and the law or court order behind it, and that any restriction should be geographically narrow when possible.

Radicle gave the source another route

By July 26, a BitChat mirror was available on Radicle under repository ID rad:z2v9tRJz1oknFAqCSY5W5c76nVvm6. Radicle is a peer-to-peer code collaboration network built on Git. Its repository identity, signed references, and copies live across participating nodes instead of under one hosting company's account system.

The Rosa seed node reported 66 seeders for that repository when we checked. That does not mean there are no servers or organizations to pressure. A web gateway, a public seed node, or a developer can still be blocked. It means no single one of them holds every copy. Radicle's own availability model is simple: a repository remains available while at least one reachable node keeps seeding it.

The viral version says the code was back on Radicle before the three-hour deadline. The public evidence we found does not establish that timing, so we are not repeating it. The mirror also carried commit 733098b from July 10 while GitHub's main branch had moved to ca18843 on July 25. Replication preserved a copy. It did not guarantee the freshest copy. Availability, freshness, authorship, and safe installation are four separate jobs.

What this means for our customers

Most products do not need a Bluetooth mesh or a peer-to-peer forge. Every product does need an honest answer to one question: what value can the customer still receive when the primary service, network, vendor, or policy gate disappears?

• Keep critical work local first. Let a field form, queue, checklist, or message work offline, then sync when a route returns.
• Use more than one delivery path when access is part of the product promise. A web app, signed native client, export, and verified mirror fail differently.
• Separate availability from trust. A thousand mirrors are dangerous if customers cannot verify which build and signing key are authentic.
• Design explicit recovery. Queued work needs expiry, deduplication, retry limits, conflict rules, and a visible failed state.
• Test the real outage. Turn off the internet, kill the app, lock the phone, remove the main host, and measure what customers can still finish.

What this changes for GattyWorks

We build fast, but speed should not quietly make one vendor the only path to the customer's value. For products used in the field, during travel, around weak networks, or under policy pressure, we will ask about offline state and alternate distribution before choosing the default architecture. A resilient build may be as small as an encrypted local queue and a signed export. It may need a second sync transport. Only a narrow set of products need a full mesh.

Decentralization is not a magic shield. BitChat still needs installed phones, Bluetooth, battery, enough nearby peers, safe builds, and people who keep the source current. Radicle still needs seeders. The goal is to stop one dependency from breaking the whole value chain.

Next step: take the most important customer action in your product and run one tabletop test. Remove the internet, your main API, and your primary distribution host in turn. Write down which failure loses data, which only delays it, and which blocks the customer completely. That list tells you where a second path is worth building.