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.
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 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.)
What is going on underneath? Are you guys using WebSocket or WebRTC? The reason I ask is because I wrote an interactive coding tutorial for building a distributed chat app ( http://gun.js.org/converse.html ), and it uses WebSockets to communicate with a federated relay peer server. I'm hoping to add WebRTC support but I'm curious what you guys are doing. Like, IPFS doesn't have pub/sub support right? So did you add this?
 - https://github.com/haadcode/ipfs-daemon/blob/master/ipfs-dae...
Most questions have been already answered, but to clarify:
Orbit indeed uses IPFS pubsub (https://github.com/ipfs/go-ipfs/pull/3202) for real-time message propagation, no servers are involved. In addition, it uses orbit-db (https://github.com/haadcode/orbit-db) - a distributed database on IPFS - for the message history, so the messages are not ephemeral and the channel history can always be retrieved. This is a really nice property and allows Orbit to work in "disconnected" or split networks, as well as offline.
Orbit has been a testbed for IPFS applications and orbit-db came out of that work, enabling various types of distributed, p2p applications and use cases: comment systems, votes/likes/starring systems (with counters), feeds, etc. And now with IPFS pubsub, we're finally at a point of being completely serverless and distributed which is hugely exciting and opens so many doors for future work!
I recently gave a talk at Devcon2 about Orbit and developing distributed real-time applications (https://ethereumfoundation.org/devcon/?session=orbit-distrib...) and while the videos of the talk are not out yet (afaik coming very soon!), there's the uncut video of the talk here http://v.youku.com/v_show/id_XMTc1NjU1NzEyNA==.html?firsttim... if you're interested to learn more. Video of the demo I showed in the talk is here https://ethereumfoundation.org/devcon/wp-content/uploads/201....
I'll be hanging out on #ipfs in Orbit if you're interested to try it out. Note that the Electron app and the web version at orbit.libp2p.io don't talk to each other atm (we're working on this), so I would highly recommend to try out the Electron app.
While you're at it, try drag & dropping files and folders to a channel, that's one of the coolest feature of Orbit atm imo :)
We're actively developing Orbit and making a push in the next few months, if you're interested to take part in the design and development, or would like to develop your own apps using the same tech, join us on Github https://github.com/haadcode/orbit/issues.
Thanks for the comments everyone, much appreciated!
But since I posted the comment I realized that this is actually a cool feature for a chat app to have.
More concerning to me is with IPFS is privacy. I would want to encrypt it so that only my chat partner and I could read it. But then would it be interesting in enough to live for long on the network?
The name of a piece of data is cryptographically secure. It is permanent, but the data that is being named doesn't have to continue to exist on a hard drive just because its name exists.
Linked data ftw! :)
There are also improvements upon Kademlia such as S/Kademlia which we've partially applied to IPFS (and we'll continue to apply more).
Splitting routing into peer routing and content routing isn't going to fix this if you're still using a DHT to do both. Also, S/Kademlia's decentralized countermeasures only slow down the attacker, and they don't save you if the attacker has a botnet.
> We're planning ahead for future mitigations by making every layer of IPFS pluggable.
The problem with this line of thinking is that it ignores the fact that IPFS-with-DHT-routing is a fundamentally different system than e.g. IPFS-with-DNS-routing, which are both fundamentally different from IPFS-with-Namecoin-routing. This is because they each make fundamentally different guarantees about availability, durability, and security. In general, the end-to-end properties of a distributed system do not logically decompose.
Plugins make this problem worse, not better. Now it's not enough to know that I'm storing my data with IPFS; now I also need to know which plugins both I and my peers are using using since the set of plugins is what determines the properties of the data store.
By now redis has been replaced with native IPFS pubsub, which is provided by both go-ipfs and js-ipfs. The only remaining server-ish is some means of bootstrapping, i.e. entering the network.
I'm not sure how up-to-date the readme is, but the demo (orbit.libp2p.io) is out-of-date and still uses redis pubsub. I pinged @haadcode, who can go more into detail.
I'm quite surprised to hear what you said. I've been following multiple Github Issues on IPFS pubsub, and none of them (that i followed) announced success/etc. I thought it was still in the planning phase.
$ ipfs pubsub --help
ipfs pubsub - An experimental publish-subscribe system on ipfs.
ipfs pubsub allows you to publish messages to a given topic, and also to
subscribe to new messages on a given topic.
This is an experimental feature. It is not intended in its current state
to be used in a production environment.
To use, the daemon must be run with '--enable-pubsub-experiment'.
ipfs pubsub ls - List subscribed topics by name.
ipfs pubsub peers - List all peers we are currently pubsubbing with.
ipfs pubsub pub <topic> <data>... - Publish a message to a given pubsub topic.
ipfs pubsub sub <topic> - Subscribe to messages on a given topic.
Use 'ipfs pubsub <subcmd> --help' for more information about each command.
Time to dig into this a bit!
edit: For anyone else perplexed and surprised by me, seems `floodsub` is their moniker for the new tech, and it was (in part) merged in here: https://github.com/ipfs/go-ipfs/pull/3202
This is really, really cool! Also, if this implementation is robust and performant, this is huge for IPFS.
Note on the name: floodsub is one specific implementation of pubsub. There are many ways to do pubsub, and we chose to go with a naive and simple flooding implementation for now. In the future there will be more, and you'll be able to use different implementations simultaneously.
Now, one avenue to handle that is js-ipfs. In order to update things like IPNS records, you need the private key of the node you're trying to change. Interestingly enough, and machine with the pub/priv key can submit an IPNS change.
So effectively, you could have a shared repo like Usenet, where everyone has the pub/priv key and pushes updates via js-ipfs. Although, I could imagine easily how that could get super-heavy.
Another idea I had, was to build something akin to AWS lambda, except using Tor Hidden Services, and Erlang. It would be effectively a private computation cloud. The reason for the HS is so each machine, regardless of their location, could always talk with each other, using Erlang's built--in networking support. (I am using non-standard applications of Tor Hidden Services - read more what I'm doing here: https://hackaday.io/project/12985-multisite-homeofficehacker... )