IPFS is a p2p network, designed with content-addressability in mind. It currently allows to:
IPFS does not store any data on your node you don't command it to. Only DHT entries (like "that hash is likely stored by IP 4.5.6.7" or "that IPNS entry last pointed to QmFoobar") are stored in your cache.
IPFS can traverse NAT, so you can host data even if you're behind one.
Data in IPFS is stored in directed acyclic graphs, or DAGs. That structure allows easy storage of tree-like structures like file trees. Every point of DAG can be identified using its hash like QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv. Tree hashing ensures no part of the DAG can be modified without the hash being changed.
IPNS is system of cryptographically signed records which allow you to update your data in decentralized manner. So, you generate a key with public key QmFooB4r and sign a record that says QmFooB4r=QmArB4z. Now, everybody who requests /ipns/QmFooB4r gets pointed to /ipfs/QmArB4z.
There are public HTTP gateways which allow to access IPFS without installing software. Most well-know is at https://ipfs.io, just add /ipfs/<hash> or /ipns/<hash> to access data. Bitcheese.net has its own gateway, but it works only for data already hosted by the server.
IPNS does not work well. It's intended to be replaced with more universal IPRS and current implementation of IPNS is hackish (problems are in software though, not in the protocol). It cannot be re-seeded by any nodes than original one and record time-to-live is 12h nax, that means that IPNS entries actually are centralized. It's also just not reliable for some reason.
Currently, no real standard exists on IPFS links. There are two kinds of links: "filesystem" ones:
/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/start
/ipns/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/start
They are supposed to be useful if IPFS is mounted in your root. But such links are hard to detect in text, and can't really represent non-hierarchical parts.
And there is ad-hoc "gateway links" pattern:
http://ipfs.io/ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv
http://gateway.godforgotten.us/ipns/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv
Common part is /ipfs/ path start. That's how browser extensions like ipfs-chrome-station detect these links and redirect them to local ipfs daemon.
Pros:
Cons:
Currently, fs: and ipfs: URI schemes are proposed. fs: is kind of megalomaniac, but this is sane starting point
A piece of data can be described in multiple ways. For example, if there is a DAG with hash QmFoo, inside via path "foo/bar" there is chunk with hash QmBar, and QmFoo is published under public key QmLink, all of following URIs will lead to the same data:
ipfs:/ipfs/QmBar
ipfs:/ipfs/QmFoo/foo/bar
ipfs:/ipns/QmLink/foo/bar
The latter two of those links are also not reliable in the long run: for second one QmFoo still needs to be present in network, and for the last one IPNS entry still need to be around.
While IPNS and parent can certainly be useful, links should be as permanent as possible. Base link should be pure data linked, and parent info with IPNS snapshot can be present in query part. So, links to IPNS entries with path context should look something like:
ipfs:/ipfs/QmBar?context=/ipfs/QmFoo/foo/bar&ipns=/ipns/QmLink
It's also sometimes desireable to attach filename to the file linked. Creating an envelope DAG so that we can link to /ipfs/QmEnvelope/file.mp3 introduces probably poorly-seeded bottleneck, so it's another thing that should be added to URI itself:
ipfs:/ipfs/QmBar?context=/ipfs/QmFoo/foo/bar&ipns=/ipns/QmLink&filename=file.mp3
Downloading content in IPFS automatically seeds it, but go-ipfs daemon also supports "pinning", If you want content alive, you can ipfs pin add it. Unfortunately, IPNS pins (both ipns entry itself and updated contents) are not implemented yet.
Pins are hard to keep track of, though, because pins are not named and you have to dig into data itself to see if it's still worth keeping. But there's also a file system under ipfs files which you can use for basically same purpose, since it's also protected against GC. It does not download data for you, unlike pins, so you have to run something like ipfs refs -r QmFoo to get it.
If you can't host content yourself, you can pay other people to do it. One IPFS hosting service
Everything you share on your IPFS node can be easily downloaded and traced to your IP address. If you want to securely share files, use encryption (GPG, for example). If you do not want to be traced, use some kind of VPN, like Tor.
Also, if you're using `ipfs files`, there's a neat DAG node shared with all your file structure.