I don't really see how your 'competing for resources' scenario would work. New peers that try to fetch the new content at some IPNS name would see a new IPFS ob

I don't really see how your 'competing for resources' scenario would work. New peers that try to fetch the new content at some IPNS name would see a new IPFS object hash, and search the DHT for that new hash. Nodes that have an old version won't be involved (unless of course the object 'hierarchy' contains cached data, which will only speed things up). At first the only peer having the new content will probably be the creator, but this will quickly spread across the network. As long as peers do not decide to keep the data (by pinning the hash), the old content will simply be deleted and replaced with new content. Pinning is extremely cheap, so you can imagine that you would want to auto-pin pages as you visit them. This is not on by default though, and I think that's a good thing. > [B]ut without a central management how does IPFS associate correct file to the correct hash? It does so using cryptographic identities. In IPFS every peer has a private/public keypair, and the PeerId is the hash of its public key. When publishing content under an IPNS name (which always has the PeerId at its root), you must prove that you 'own' the PeerID by signing the object with your private key. Other nodes will not 'mirror' your IPNS object unless the signature matches (which makes a nice consensus). The paper calls this self-certified names: you can distribute the objects, and let them be provided by third parties without losing authenticity. See section 3.7.