This is Iran's third total internet shutdown, but the methodology has evolved into something far more surgical. They didn't just block IP addresses; they severed BGP routes, killed mobile data, and effectively jammed Starlink signals into a dead zone thanks to Russian imports. When the signal itself is murdered, your Tor bridges and VPNs become expensive paperweights.
As builders, we are being out-engineered. We have grown complacent, assuming the "always-on" cloud is a fundamental constant of the universe. But if your software requires a remote handshake to function, it is a liability, not a tool, in a crisis zone. Every application built with heavy reliance on centralized APIs vaporizes the moment the backbone is cut.
We must stop designing for the "connected" illusion and start building for the darkness.
This is my plea to the HN community: stop treating "offline-first" as a niche feature and start treating it as a human right. We need robust, decentralized mesh networks that bypass state-controlled gateways entirely. We need isolated documentation tools and local-first databases that can sync via Bluetooth or physical handoffs.
Build for the 212 regions that went dark last year so that the next time a state pulls the plug, the people aren't left helpless.
a throwaway account for obvious reasons (they have also Chinese tech to track); make your code work when the world goes quiet.
I don’t want to downplay the seriousness of the problems in Iran, but switching to a world where tools are design first for syncing via Bluetooth and offline methods just isn’t going to make a better world for all of us.
You need specialized tools for specialized situations. Trying to get the whole world to pay the overhead of mesh networks and Bluetooth handoffs and all of the design choices that go along with it would be a mistake.
The software world is not monolithic. Pleas for everyone to stop building for the way the world works and start building for highly unusual and specific use cases isn’t reasonable.
Build specialized tools for specialized circumstances. They will always serve the purpose far better than if you try to get everyone to build their general purpose tools around extremely rare circumstances.
Expecting a robust ecosystem of offline-first apps, ideally compatible with everyone else's existing apps, would be awesome.
An opt-in facebook streaming offline mode where posts are queued and sent...
or an opt-in signal mode where p2p messaging is possible via transient connections (imagine the data mule movie that would be coming out in 2030). All this is technically possible, just not prioritized.