There are people in turkey replicating this snapshot right now. people browsing locally get it there. Even if all connections to outside the country get shut down it can be distributed locally.
But it won't grow unless others can download IPFS software to continue hosting it and there is no reason to believe they could not simply block it internally as well to prevent spreading.
As said before, it needs to be used/useful to many normal people (like a previous example of GitHub) before there it requires too much political will to effectively block.
Installing software from a USB drive is within the reach of most normal teens and young adults in the developing world. So, sneakernet -> IPFS -> Wikipedia is a viable path so long as blocking the IPFS protocol, over all reasonable transports, is hard enough to do.
Responding to 0xCPM (sibling comment). IPFS was not designed to hide the sources but thanks to versatility of transports (you can ever run it on cjdns or mesh network) and possibility of using it offline it is not easy to censor.
The person I was responding to was talking about people getting the IPFS software via IPFS or in person delivery of media. This is not a promising method for distributing anything to normal people, even if it later lets you view Wikipedia.
What prevents Turkish ISPs from blocking peer-to-peer IPFS connections within the country?
(I'm having trouble figuring out exactly how IPFS presents itself at the network layer, and whether an IPFS connection over TCP/IP is noticeably different from some other normal connection type, so I genuinely don't know the answer to this question. It looks like it uses SPDY over TLS, but maybe something in the certificate gives it away?)
I was wondering the same, but knowing the kind of DPI equipment that has been sold to Syria, Lybia and other countries I assume that it possible to detect, monitor, tamper and block pretty much any kind of traffic, including IPFS.
I don't know how to make this work with IPFS' P2P approach: a request for www.google.com with a destination IP of some residential Turkey customer looks awfully suspicious. I suppose it's workable if App Engine has a colo inside Turkey.
There's a circuit switching relay protocol [1] in the works which will allow multi-hop connections. This is generally useful for situations where two nodes can't directly connect to each other, be it because of NAT, censorship, or simply because they don't have a transport protocol in common (e.g. js-ipfs in the browser).
That means nodes can soon use the Websockets transport to connect to a domain-fronted node (this part already works), which then acts as a relay.
Connections over the libp2p-tcp transport are trivial to spot, but there's more transports available (Websockets, WebRTC, UTP), and even more in the works (Onion, QUIC, FlyWeb).
