If you're looking for the in-depth technical detail of IPFS, you really want to read Juan's paper on it: https://github.com/ipfs/ipfs/raw/master/papers/ipfs-ca

If you're looking for the in-depth technical detail of IPFS, you really want to read Juan's paper on it: https://github.com/ipfs/ipfs/raw/master/papers/ipfs-cap2pfs/ipfs-p2p-file-system.pdf https://github.com/ipfs/ipfs/raw/master/papers/ipfs-cap2pfs/... I've explained IPFS to friends in the past: Imagines IPFS as running Git where all of the objects (files, directories, commits, etc) are available over a BitTorrent swarm. All files are accessed via their checksum so they have cryptographic integrity even over insecure networks. Then imagine you can mount it as a file system or browse it via HTTP, and run your own node to seed files. Popular files will be seeded by more people, making them quicker and more reliable to access. As long as clients are still requesting a file, it will continue to be seeded even when the original publisher goes offline. Pitching a developer product is hard. Traditional marketing advice encourages you to pitch value because the implementation details are usually not important to your customer. Developer products require a more delicate balance because ultimately we have to work with the technology and want to understand what its real limitations are.