My (imperfect) understanding is that it runs like a market: you temporarily store and forward blocks (<1MB) that are considered "valuable" (i.e. popular) in exchange for people forwarding you the blocks that you want. So there's a cache at each node where popular blocks are held - which I'm sure you can keep in RAM if you want. So while it's possible that content you don't want might pass through your IPFS node, it's pretty ephemeral.
In general, I don't think IPFS is a great place to do naughty things - it's not big on anonymity, and since blocks drop off the network if they're not being actively requested, to keep something up there you have to store it permanently _somewhere_, which is going to be traceable to the same degree that running a webserver is.
Things in local IPFS cache can indeed be "garbage-collected" (and there's a CLI command to trigger GC manually) — but IPFS daemon has a concept of _pinning_, and pinned IPFS nodes won't be collected, and will remain stored (and being shared) as as the pinning goes.
In fact, IPFS via the DHT, tells the network of your whole network topology, including internal address you may have, and VPN endpoints too.
There's still talks in how to handle Tor connections. Because right now, if you were to use a Tor connection with IPFS, it will tell the whole network your public, private, and .onion addresses all.
What IPFS does, is looks at network topology to determine 'closeness' of nearby IPFS nodes. It then prefers 'closer' nodes, to speed up transactions and requests.
For example, if we take Gangnam Style video, it spread to something like 100M views rapidly. With Youtube, that's 100M individual downloads. With IPFS, it would be 1 or 2 downloads per local network. And then those machines would provide the local network with the content, rather than hitting the 'net at large.
The only good way to do this, is to include all the adapters in the DHT to where all machines are. It also allows IPFS to seamlessly work across NATs and other junky applications of IPv4 (and egads, already seeing ipv6 nat).
But for working with data that's intended to be open, it's wonderful.
IPFS is an infrastructure building block. You are judging it by throwing out "privacy" like all things need to implement privacy without regards to the fact it's the application layer that should be responsible for the "security" of the "private" communication.
I could seed an encrypted file on IPFS and then put a bounty out on it for people to cache it aggressively. I'll increase bounty if you've cached for me before and I'll increase bounty for anyone caching it around a particular timeframe. Any agent looking for my contact who is downloading that file doesn't know if they know the file is for my contact or not.
You can of course already encrypt the data yourself before adding it to ipfs.
I'm curious because I've seen objections to Freenet for that reason yet the content stored is in no way CP. No bad content can be reconstructed from the data in your store. Not just because it's encrypted but because you'd be holding random small chunks of the file.
The vast majority of Freenet content is probably about Freenet itself (Web of trust data, Sone traffic, FMS traffic), not bad content.
You share:
1. Files you Pinned (think of as torrent seeding)
2. Files you have in your IPFS cache
a. Cache files are added to when you request IPFS content
b. The garbage collection triggers and removes non-pinned content at regular intervals
To answer the GP's question: As long as you don't pin child porn, and you don't look for child porn, there's 0% chance in IPFS-land.
a. Cache files are added to when _something causes a request for_ IPFS content
If content on IPFS (ie a web page?) can reference and load content from other addresses (assumption) then could someone end up in the situation where they are "hosting" (from the cache) something they would not expect to be? (until the garbage collection clears it).
If this seems far fetched, A submission to HN the other day seemed to surprise a few people[1] as it made a http request to a adult website to check if they had an active session (but did not display any content).
Child porn already exists on the web directly. And Tor Hidden Sites. And Freenet. And other places.
The real problem with CP is that fact there's no mens-rea requirement. A script can download it to your browser cache under blank images. It's in your cache, and you have no clue.
In the current situation, you are illegal. With mens-rea, you aren't - there was no willingness to get it, therefore you aren't at fault. Think of this as shoplifter compared to something that fell in your cart you missed. Same idea.
(In all honesty, I hold to Stallman's idea of CP shouldn't be illegal, period. It's a proof of a crime. Snuff videos of people being murdered isn't illegal, although the murdering part very much is. Child abuse is illegal, as well it should be, but proof of child abuse shouldn't.)
https://blog.ethereum.org/2016/01/15/privacy-on-the-blockcha...