[geofft]

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?)

[bigbugbag]

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.

[geofft]

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.

[lgierth]

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

[lgierth]

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).