Adressing mutable content

Ecosystem
1

On the roadmap for ipfs on Github I see that “Support for mutable links to files, websites, data” is checked. How is it implemented ? (As IPNS can only target one hash and it’s subfolders, I do not consider it to be the full implementation but I appreciate the hack)

I checked this issue on Github about mutable content and saw the mention of pubsub (which from what I understand is just like a RSS feed) and [https://github.com/ipfs/POST](http://IPFS POST) for which I couldn’t find any documentation. I also checked this issue but the links seem dead. I couldn’t find anywhere else a proposition to tackle the mutable content adressing issue.

One thing that I think could work would be a file (I call that file a link file) with a fixed hash (I call it a page hash), the content you want to point to (the content hash), a network checked timestamp and a signature to verify the publisher’s identity.

This way, if someone wants to publish a website, they give you the page hash. If he wants to modify the website, he just needs to change the content hash and verify that he is allowed to change the content hash.

The content hash could be a ressource hash or a page hash.

If the webpage links to other ressources on the network that are supposed to change over time (like in a wiki for example), the link is the page hash. You could even link to page hash you can’t modify yourself.

If someone else wants to modify the website, he needs to have the key to change the file content and sign it. Page files with the same page hash but older timestamps should be deleted from the network.

I believe this would also solve the cyclic content issue (while raising the issue of one page hash linking to itself).

You could also include a version system in the link file to have access to contents or pages that used to be linked to that page. I see several ways we could do that:

  • put the hash of the previous link file in the new file, but if one file is no longer available, the link will break
  • append the new content / page hash to the list of the previous file hashes
  • append the new content / page hash to the list of the previous content / page hashes
  • append the new content / page hash to the list of the previous content hashes (following any page hash to it’s content at the time the new file is created
  • mix the last two

One issue I can see is how do you generate the page hash (it should be random but still be linked to your authorisation key for modifying it). If multiple people having the same authorisation key want to publish a new page, how do you prevent them from generating the same page hash ? You could base it on a timestamp and a nodestamp for randomisation but need to be careful about the ability to identify a publisher based on the nodestamp.

What do you think of this method for mutable content and do you think it respects the philosophy of IPFS ?

1 Like
2

Besides built in timestamps (I think), how is this different than what IPNS currently does (if you replace “page hash” with IPNS address and “content hash” with IPFS multihash? The current IPNS implementation isn’t planned to be the final one as far as I know, so I wouldn’t be surprised if the developers added the ability for IPNS pointers to be cached and pinned giving them similar resilience to IPFS multihashes.

3

As far as I understand, IPNS is linked to the node. This limits to one “page hash” per node. This also prevents modifying just one page (you need to hash the whole website again) and prevents a team from modifying the IPNS content. IPNS is also limited in the fact that they need to be renewed every 12 hours.

As far as I understand, what you mean by cached is a way to distribute the content adressed by an IPNS adress and pinning is just updating your local content to one IPNS content.

As far as I understand IPFS multihash, this is just to allow the network to change the hash function (although it could be used as an identification for the kind of hash, i.e. page or content).

4

You are not limited to one IPNS address per node. There is a default IPNS address for your node, but new IPNS addresses can be created using the ipfs key command.

When ingesting content into IPFS using ipfs add, adding content that hasn’t changed doesn’t incur the same cost as adding content that has. I’m not sure how you’d get around at least checking to see if a file’s content has changed.

As for a team modifying what an IPNS address is pointing to, there’s nothing that I’m aware of stopping multiple people with a specific IPNS key from publishing updates using the same key.

That is a benefit of using a multihash, but the only reason I mention it is because it’s the identifier for addressing immutable content in IPFS. For example, QmNvTjdqEPjZVWCvRWsFJA1vK7TTw1g9JP6we1WBJTRADM.

5

So after your comments the only advantages I see for the system I explained are:

  • Ability to link a mutable page to any page without needing to update the link should the linked page be changed. [1]
  • Ability to group pages under one key. [2]
  • Should the version system be implemented, by able to see every pages / ressources this “page hash” used to point to. (Updated the version system part on the first message)

The issue if you host a website is that you need a new folder with files for every page you have that might change.

I think it would be nice to have some documentation about IPNS, because I don’t think I fully understand it and what it offers. But from what I understand, it is too much linked to the node to be a system used to point to mutable content. This link helped me understand a bit more about it but I am still not confident with the subject. If you have any links about the way it will eventually work, feel free to send them.

[1] Also you could have an IPNS adress for each page, you still need to update the DHT table every 12 hours.
[2] With IPNS you have one keypair for each page (not exactly sure about this one).