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.

You can download IPFS software via IPFS, and there is always sneakernet.

> As said before, it needs to be used/useful to many normal people

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.

According to another comment on this thread: Unfortunately IPFS wasn't designed to hide and would be easy to block for a nation state.

Are you arguing that providing a mirror of localized wikipedia is not useful to normal people ? Or am I missing your point ?

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.

It's possible to design DPI-resistant protocols; see e.g. domain fronting (Fifield et al. 2015, https://www.bamsoftware.com/papers/fronting/), which uses HTTPS connections to popular CDNs where all unencrypted data (target IP address + SNI header) look just like normal connections. Tor supports this (https://trac.torproject.org/projects/tor/wiki/doc/meek).

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.

[1] https://github.com/libp2p/specs/tree/master/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).