One IPFS capability that's essential for interplanetary file systems is how well it tolerates poor and unreliable network connectivity (latency and jitter, packet loss, network flapping, etc). But its key limitations are the lack of anonymity and deniability. IPFS is a P2P swarm, so each node may eventually peer with every other node. And unlike Freenet or I2P, data requests are not proxied to give even plausible deniability.
However, tolerance of poor and unreliable connectivity makes IPFS a perfect match for anonymizing overlay networks. The major public ones are Tor and I2P. And I get that IPFS developers are exploring how to add Tor and I2P connectivity (see issues 1118 and 37).
Alternatively, at least in the interim, there's OnionCat. It overlays IPv6 /48 VPNs on Tor and I2P, assigning addresses based on Tor onion hostnames and I2P server destinations. OnionCat via I2P is also called GarliCat.
By default, IPFS listens for swarm peers on all local addresses (IPv4 0.0.0.0 and IPv6 ::). Even if inbound packets to an adapter are dropped in the firewall, the node's Peer.ID still includes those IP addresses. However, one can configure IPFS to listen for swarm peers only on a particular IP address. In that case, the node's Peer.ID only includes the specified IP addresses.
I have a few nodes that listen for swarm peers only on their OnionCat IPv6 addresses. They work quite well. Latency is typically 300-500 ms, and IPFS transfer speeds are decent, on the order of 3-6 Mbps. However, there's no direct connectivity to the default clearnet swarm, so only stuff from OnionCat peers is available (unless a peer has clearnet connectivity). But if anonymity matters, that's arguably an acceptable trade-off.
Still, if anonymity is crucial, relying solely on IPFS configuration seems iffy. Rather than hiding a public IP address, it's better to not have one that needs hidden. And so you run IPFS in a (virtual) machine on an isolated (virtual) network, and access Tor through a gateway (virtual) machine, which does have a public IP address. Even if IPFS were listening for swarm peers on all local addresses, only the OnionCat IPv6 address would be reachable.
If both anonymity and connectivity to the default clearnet swarm are important, one can use an anonymously leased VPS as a proxy. And by linking an otherwise-isolated IPFS node to the proxy via OnionCat, the node's anonymity is preserved. But there are two problems. First, finding VPS providers that respect privacy is nontrivial. I'd love to share which providers I've used, but that wouldn't be prudent. Also, the situation is fluid. Useful sources are Tor Project's GoodBadISPs, City of Hackerzx and Bitcoin VPS. Do pay with Bitcoin that's been anonymized by mixing through Tor, at least twice, using independent wallets.
The other problem is IPFS throughput. By default, IPFS nodes handle routing and data trading (bitswap) for peers. My OnionCat/clearnet node idles at ~10 GB per day total (~5 GB per day in each direction). That is, I admit, a lot of data to be routing through Tor. More generally, it's a lot of data to be routing through metered Internet uplinks. IPFS developers are also working on this and other resource-management issues.
There's a public gateway at <http://yvjsuxfapdwwxjrr.onion:8080/ipfs/> It's on an OnionCat-only node at "/ip6/fd87:d87e:eb43:cafe:a090:c13d:adb2:bf86/tcp/4001/ipfs/QmcnSFQwSmGfUvWujiZ7UjPTw9fDqz5UFz9Td1abNTQUmr". You are perhaps reading this document through that gateway. But also see, for example, this silly onion image. Everything added or pinned on nodes that peer to it via OnionCat should be available through it. Also, if one of its peers has (or has recently had) connectivity to the main clearnet swarm, anything on IPFS should be available through it. Such as this silly image.