In Nepal this past September, authorities blocked 26 major platforms including Facebook, YouTube, and WhatsApp, triggering Gen Z-led protests that ultimately toppled the government. In Uganda ahead of the January 2026 elections, opposition leader Bobi Wine urged citizens to download resilient communication tools, citing the four-day internet blackout during the 2021 elections. Similar patterns emerged in Indonesia during August protests over government corruption.

In each case, citizens turned to Jack Dorsey's Bitchat—a Bluetooth mesh networking app that operates entirely without internet infrastructure. Downloads surged from 3,000 to nearly 50,000 in Nepal within days. Uganda saw hundreds of thousands of installs in just 48 hours, representing roughly 1% of the population.

These aren't just technology adoption statistics. They represent people's fundamental need to communicate during critical moments—to coordinate, verify information, and maintain connection when traditional infrastructure fails.

The Technology Behind Crisis Communication

Bitchat works through Bluetooth Low Energy mesh networks, with each device acting as a node that can relay encrypted messages up to 30 meters to the next device. In crowded areas like protest gatherings, this creates an ad-hoc communication network that exists entirely independently of internet service providers, cellular networks, or any centralized infrastructure that governments can disable.

Dorsey’s app requires no account creation, no phone number verification, and no central servers. Messages hop between devices in range, creating resilient pathways for information to flow even when traditional communications are severed.

For protesters in Kathmandu facing a social media blackout, this meant the ability to coordinate peaceful demonstrations, share real-time information about police movements, and maintain community connection during a crisis that ultimately left at least 30 people dead.

A Different Kind of "Downtime"

Here's a strange parallel for enterprise technology leaders: Remote workforce faces connectivity challenges that, while less dramatic, follow similar patterns of disruption.

Consider:

• Field service technicians in rural areas or remote job sites with spotty cellular coverage
• Retail associates whose point-of-sale systems go offline during internet outages (taking with them the ability to process transactions, access inventory, or coordinate with other locations)
• Healthcare workers in disaster response scenarios or underserved areas with unreliable infrastructure
• Manufacturing floor workers in facilities with dead zones or where connectivity is deliberately restricted for security reasons
• Transportation and logistics workers moving through areas with intermittent coverage

When Nepal's government cut access to major platforms, Gen Z protesters lost their primary means of coordination and communication. When your restaurant's internet goes down during dinner rush, your staff loses access to the POS system, kitchen display screens, and the ability to process digital payments—leaving servers with pads of paper and a kitchen in chaos.

The root cause differs, but the impact is the same: critical operations grinding to a halt because systems weren't designed to function when connectivity fails.

From Protest Squares to Commercial Spaces

The lesson from Uganda, Nepal, and Indonesia isn't about politics—it's about the fundamental architecture of resilient systems.

Protesters needed communication tools that could function in an actively hostile environment where authorities controlled the infrastructure. Enterprises need operational systems that can function in environments where connectivity is unreliable, intermittent, or simply unavailable due to infrastructure limitations.

The technological requirements include:

• Offline-first architecture that assumes connectivity will be intermittent
• Peer-to-peer synchronization that doesn't require constant connection to central servers
• Conflict-free data structures that allow devices to work independently and sync changes when they reconnect
• Mesh networking capabilities for direct device-to-device communication when traditional networks aren't available

Bitchat demonstrated these principles during Nepal's social media blackout. On September 8, when 48,781 Nepalis downloaded the app—representing 39% of global adoption that day—they weren't downloading a novelty. They were downloading a tool built on fundamentally different architectural principles than the centralized systems the government had just disabled.

Building for Reality, Not Ideal Conditions

The common thread in both humanitarian and commercial use cases is this: Most systems are designed for ideal network conditions that don't reflect reality on the ground.

Traditional enterprise systems assume:

• Stable, high-bandwidth internet connectivity
• Minimal latency to cloud servers
• Continuous connection for data synchronization
• Centralized infrastructure that's always accessible

But reality for many workers looks more like:

• Moving in and out of coverage zones throughout the day
• Bandwidth constraints that make cloud-dependent apps frustratingly slow
• Network congestion during peak hours
• Infrastructure outages from weather, construction, or provider issues

When Ugandan opposition leader Bobi Wine called for Bitchat downloads ahead of anticipated internet restrictions, he was preparing citizens for a known failure mode in their infrastructure. Enterprise leaders should be equally honest about the failure modes in their own systems.

What Resilient Systems Look Like

The protesters in Nepal, Uganda, and Indonesia didn't need perfect connectivity—they needed systems that could function in imperfect conditions. Your field technicians, retail associates, and remote workers have the same requirement.

Offline-first, edge-native architecture addresses this by:

• Storing data locally on devices so applications function without network access
• Enabling peer-to-peer synchronization so nearby devices can share updates directly
• Gracefully degrading functionality rather than failing completely when connectivity drops
• Automatically reconciling conflicts when devices reconnect and sync their changes

These aren't theoretical benefits. When Nepal's government blocked major platforms, protesters using Bitchat maintained communication because the system was architected to function without infrastructure. When a restaurant's internet goes down but their POS runs on offline-first architecture, servers can still take orders, the kitchen can still prepare meals, and the business doesn't lose revenue during the outage.

The Business Case for Resilience

There's a tendency to view these protest scenarios as edge cases—dramatic but rare situations that don't apply to normal business operations. But the underlying technological challenge is identical, just playing out across different time scales:

• Nepal's government imposed a complete social media blackout for days
• Your retail locations experience internet outages that last hours
• Your field technicians move through dead zones that last minutes

The duration differs, but the requirement remains constant: systems need to function when connectivity fails.

The protesters who downloaded Bitchat weren't making a political statement about technology—they were making a pragmatic decision about operational continuity. Enterprise leaders evaluating their technology stack should apply the same pragmatism.

Moving Forward

The mass adoption of mesh networking and offline-first communication tools during political crises in 2025 revealed something important: when people's ability to function depends on connectivity, they'll rapidly adopt alternatives that work when traditional infrastructure doesn't.

Your employees face the same calculus. When connectivity issues prevent them from doing their jobs, they need systems that were designed with resilience as a first principle, not an afterthought.

The protesters in Kathmandu, Kampala, and Jakarta demonstrated what happens when people are given tools that match the reality of their operational environment rather than the ideal conditions system designers assumed.

Perhaps it's time to ask: Are your enterprise systems designed for the connectivity challenges your workforce actually faces? Or are they designed for ideal conditions that exist more in architecture diagrams than in the field?

‍