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.
This expressed expectation of "how the world works" is the perception of a monolith, however. There is no divine right or reason for things to be designed online-first, except for incentives to the service providers. When somebody designs an app to be online-first, they are choosing to be a service provider, and not an app author. This distinction may not be clear to developers who came to be in a culture where online-first is a first order concern, but it is immediately clear to anybody who "owns" the "app" in question when the service is either neglected or decommissioned in a few years, or is otherwise made inaccessible via the internet.