Russia is preparing a nation-wide experiment where the whole country temporarily disconnects from the global Internet to see if the country can rely on Runet alone. The effort is supposed to help Russia prepare for potential digital warfare against the nation, but some analysts are also speculating whether this is the first step towards deploying a nation-spanning censorship machine like “the great firewall of China.”
This will probably cause major disruption to online services in Russia. However, I’m more interested in looking at how prepared the distributed web is for such a cut off and whether these networks will even remain operational.
The promise of the distributed web (dweb) is that it will make us less dependent on just a few huge internet infrastructure companies and enable anyone to publish globally available resources. Every person who downloads a resource also makes it available for upload to other interested users; akin to how BitTorrent and peer-to-peer file sharing works. However, neither the InterPlanetary File System (IPFS) nor the Dat project will continue to function properly inside of Russia following a Runet cutoff from the global Internet.
Dweb clients inside of Russia will not be able to reach outside clients, but their distributed networks should still mostly work for users inside the country. However, centralized components in current dweb deployments will still lead to service outages.
The Dat project also has a single-vendor dependency for DNS resolution as the project uses Google DNS over HTTPS by default. You can’t change this resolver from within the Beaker Browser, the most popular user facing incarnation of the Dat project. Google DNS do have several recursive DNS server locations inside of Russia.
However, these DNS servers can only serve cached and stale responses unless they can communicate with a Google Cloud location where the actual DNS for uncached queries take place. There are no Google Cloud locations in Russia so the system would quickly falter.
Dat also relies on a centralized tracking server for peer-discovery. A tracking server keeps track of which users claim to have a copy of a file that anyone is interested in and introduces peers to each other. The concept was popular in the early days of BitTorrent, but have become almost obsolete as BitTorrent clients have moved over to use a Distributed Hash Table (DHT) for peer discovery instead. More on this later.
The two default tracking servers for the Dat project are hosted by Hetzner Cloud and Digital Ocean with authoritative DNS provided by Cloudflare. Cloudflare’s authoritative DNS should remain functional inside Runet, but the IP addresses for the tracking servers will be unreachable. Dat will stop functioning entirely.
The story is similar for IPFS. IPFS uses DHT like BitTorrent and doesn’t rely on a centralized tracking server. However, the two main implementations of IPFS, go-ipfs and js-ipfs, both rely on reaching one of a couple of central DHT bootstrapping nodes. These nodes introduce the client to the network by giving them enough information to connect to other nodes to get them going.
These bootstrapping nodes doesn’t depend on an authoritative DNS provider, but all of them are hosted on Digital Ocean and would be unreachable from inside Runet. Assuming at least one other domestic connection within Runet at the time of the cutoff, an IPFS client will continue functioning after the Runet cutoff. If you restart the client, however, it will no longer be able to rejoin the network.
Almost all BitTorrent clients will continue functioning just fine, however. The main reason for this is that these clients keep track of DHT nodes and saves them between sessions. Assuming you’ve connected to at least one other domestic DHT node you should be able to rejoin the network after restarting the client. BitTorrent will have the same initial bootstrapping problem as Dat and IPFS.
You can discover DHT nodes from other IPFS or BitTorrent clients on the same network and bootstrap that way. You could bring your phone or laptop running an IPFS client to a friend’s house and join their Wi-Fi network and have your client learn of available DHT nodes that way. You could power down your device and take it home and have working BitTorrent from home using this method. IPFS wouldn’t remember the previously connected DHT nodes and would be just as lost.
Dat and IPFS can clearly learn from BitTorrent when it comes to making a distributed network less reliant on centralized components. Here are some actionable points for each project:
- Dat needs to stop using a centralized tracker. The project is already working on this through their Hyperswarm initiative.
- Clients need to remember DHT nodes between sessions and to reduce reliance on a few centralized DHT bootstrapping servers. This would greatly increase the network’s resilience and diversity.
- Clients should have more accessible interfaces for manually adding a new introductory DHT nodes. Something like QR codes that you could scan with your device to add a new DHT node, or another method that could be communicated person-to-person.
- The default introductory nodes should be more diverse instead of all being hosted on the same infrastructure providers.
Update (): The Dat protocol has since become the Hypercore Protocol. It no longer relies on a centralized tracking server, and has migrated to using DHT instead.
We’re still in the early days of the distributed web. The planned interruption of access to the global internet in Russia serves as an important reminder that our networks are incredibly interconnected, and that distributed networks need to do more to live up to their potential.