3 ms·

> It also means you don't need to trust the server to send you the correct content, since everything is automatically checked against its content hash. This is

> It also means you don't need to trust the server to send you the correct content, since everything is automatically checked against its content hash. This is the confusing part to me. How does updating content work? Lets say I want to visit the jstanley blog. Does this mean you can only ever publish once, because adding an entry would change the content hash? Does everyone have to contact you for the new info hash? Does ipfs work with existing DNS?

wolfgang42 9y ago
On top of the content-addressed IPFS is an IPNS layer which maps addresses to content hashes. The address of a piece of content is a public key, which is used to sign the content hash. This means only nodes in possession of the private key can change where the IPNS address points to. In addition, IPFS gateways also support a special SRV record in DNS, which can point either directly to a hash or to an address which points to a hash. (This is how you can associate a domain name to content served by IPFS. If you also point the A record of the domain to a public gateway, the gateway will automatically look up the SRV record and return the content when someone retrieves it by HTTP.) At the moment, go-ipfs (the reference implementation) only supports pinning content hashes, so if you have someone else pinning your content (like a pinning service) you have to notify them of the change. There are plans to add support for mutable pins in the future. Put in the vocabulary of git: any given commit is referenced by hash[1] and is therefore immutable; IPNS addresses are like references (branches, etc) which can be updated at any time to point to a different commit. [1]: Since the content is a merkle tree, if they've only changed a few files most of the pinned content will retain the same hash.
- Paul-ish 9y ago
  That's pretty neat. Do you know if there is protection against rollback?
  - wolfgang42 9y ago
    IPNS records have a fairly short expiry, so you have to keep republishing them. This also keeps the DHT from getting overly full of records that nobody is using anymore, but does mean that a node with the private key must be kept online. They're working on improving this situation; here's a discussion on the topic: https://discuss.ipfs.io/t/confusion-about-ipns/1414/4 https://discuss.ipfs.io/t/confusion-about-ipns/1414/4

wolfgang42 9y ago

On top of the content-addressed IPFS is an IPNS layer which maps addresses to content hashes. The address of a piece of content is a public key, which is used to sign the content hash. This means only nodes in possession of the private key can change where the IPNS address points to. In addition, IPFS gateways also support a special SRV record in DNS, which can point either directly to a hash or to an address which points to a hash. (This is how you can associate a domain name to content served by IPFS. If you also point the A record of the domain to a public gateway, the gateway will automatically look up the SRV record and return the content when someone retrieves it by HTTP.) At the moment, go-ipfs (the reference implementation) only supports pinning content hashes, so if you have someone else pinning your content (like a pinning service) you have to notify them of the change. There are plans to add support for mutable pins in the future. Put in the vocabulary of git: any given commit is referenced by hash[1] and is therefore immutable; IPNS addresses are like references (branches, etc) which can be updated at any time to point to a different commit. [1]: Since the content is a merkle tree, if they've only changed a few files most of the pinned content will retain the same hash.

Paul-ish 9y ago
That's pretty neat. Do you know if there is protection against rollback?
- wolfgang42 9y ago
  IPNS records have a fairly short expiry, so you have to keep republishing them. This also keeps the DHT from getting overly full of records that nobody is using anymore, but does mean that a node with the private key must be kept online. They're working on improving this situation; here's a discussion on the topic: https://discuss.ipfs.io/t/confusion-about-ipns/1414/4 https://discuss.ipfs.io/t/confusion-about-ipns/1414/4