h1. IPFS overview toc. h2. IPFS basics "IPFS":https://ipfs.io/ is a p2p network, designed with content-addressability in mind. It currently allows to: # Share "directed acyclic graphs":https://en.wikipedia.org/wiki/Directed_acyclic_graph with data attached to nodes # Share updateable and cryptographically protected records, which allows to distribute updated versions of data # Exchange realtime unreliable "messages":https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern 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. h3. DAGs 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. h3. IPNS IPNS is system of "cryptographically signed":https://en.wikipedia.org/wiki/Public-key_cryptography 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@. h2. Practical data storage h3. Gateways 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":http://ipfs.bitcheese.net, but it works only for data already hosted by the server. h3. IPNS 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. h3. Links Currently, no real standard exists on IPFS links. There are two kinds of links: "filesystem" ones: bc. /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: bc. 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":https://github.com/fbaiodias/ipfs-chrome-station detect these links and redirect them to local ipfs daemon. Pros: # Links are working even if you never heard of IPFS, and you can point to best gateway. # You can attach non-hierarchical elements to URI Cons: # Full of legacy # Might disincentivize IPFS node adoption Currently, fs: and ipfs: URI schemes are proposed. fs: is kind of megalomaniac, but this is sane starting point h3. Linking strategy 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: bc. 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 h3. Keeping content available 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":https://pinbits.io/pages/pin-something.html h2. Security notes 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":https://gnupg.org, for example). If you do not want to be traced, use some kind of VPN, like "Tor":https://torproject.org. Also, if you're using `ipfs files`, there's a neat DAG node shared with all your file structure.