Right now with IPNS, you only get the last published content. I was wondering if there is support of history, where the previous state can be retrieved. Basically be able to see revisions of contents published with IPNS.
IPNS is the first place I thought of where audit/history logs can be. Are there other parts of IPFS that could history related information can be extracted?
Seems I am not the only one thinking about this, and this question has been asked before…sadly the answer to my question is No…not currently supported.
IPNS is just a simple pointer from Key to Path, where the path can be any Path-like structure (e.g. /ipfs/QmXYZ, /ipns/bafyabc, /ipns/mydnslink.com/myField). However, if you want to layer other application later semantics onto the pointer you can enforce those yourself.
For example, say your data went through 4 versions A, B, C, D instead of pointing the IPNS record at D, you could instead point it at the root of a new structure which is an append-only log (D -> C -> B -> A). Your application would then have access to all the versions of the file. You could even enforce that users that get the latest version of the log verify that the latest version in fact appends onto the previous version and if not then throw an error that the log has been tampered with.
As I understand it, the IPNS system is basically a signed pointer record, as you said of Key to Path. If that is the case, previous signed pointers should still exist within the network right? It is not like new pointer records, destroy previous ones.
Time T1 -> IPNS publish --key=KeyPath-> Signed Record T1 of Key to Path
Time T2 -> IPNS publish --key=KeyNewPath -> Signed Record T2 of Key to NewPath
After T2, the Signed Record T2 now points to NewPath, but the previous Signed Record T1 isn’t destroyed right? and is still within the network?
@dadepo you’re not wrong in theory in that each IPNS signed record lives independently from the others. However, we need to have some system that:
Allows me to tell people that I have created a new record R2
Tells people how to find the latest record, R2, so that they don’t end up with an older version by accident
The commonly used systems for publishing and searching for IPNS records are:
The Public DHT
DHTs are Key-Value stores and in a public network like ours you have to be worries about peers that were holding the IPNS records going offline, that’s why we republish them every so often.
While we could, with some modifications to how IPNS works in the DHT, always put the entire history of IPNS keys to the DHT that would be expensive both in the amount of bandwidth used and in the network having to store that data for you
IPNS over PubSub
Mostly just broadcasts the updates to the network
Has some layering on top of vanilla libp2p pubsub so that you automatically ask peers about the latest record they’ve seen
While extending this to be able to ask for all of the prior versions would likely be less expensive on the network than the DHT, it’s still more expensive
So while you can, especially in the DHT, sometimes find older records in addition to the newer records (e.g. try ipns name resolve --stream) you will not find all of the records since the beginning of time.
Overall keeping the IPNS pointer simpler and allowing any application specific operations (e.g. history tracking) to be delegated to the data structure IPNS points to should make it more reusable across applications without wasted resource usage.