# Audit/History log possible in IPFS/IPNS? **URL:** \ **Category:** Help\ **Tags:** go-ipfs, ipns\ **Created:** [June 25, 2020, 6:09am UTC](https://discuss.ipfs.tech/t/audit-history-log-possible-in-ipfs-ipns/8502 "2020-06-25T06:09:29Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![dadepo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/dadepo/32/3667_2.png) [@dadepo](https://discuss.ipfs.tech/u/dadepo)\ **Post date:** [June 25, 2020, 6:09am UTC](https://discuss.ipfs.tech/t/audit-history-log-possible-in-ipfs-ipns/8502/1 "2020-06-25T06:09:29Z")
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? Edit: Seems I am not the only one thinking about this, and this question has been [asked](https://discuss.ipfs.tech/t/history-versioning-of-documents-ipfs-ipns/564) before…sadly the answer to my question is No…not currently supported. ---
**Author:** ![adin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/adin/32/2679_2.png) [@adin](https://discuss.ipfs.tech/u/adin)\ **Post date:** [June 26, 2020, 7:21pm UTC](https://discuss.ipfs.tech/t/audit-history-log-possible-in-ipfs-ipns/8502/2 "2020-06-26T19:21:53Z")
> No…not currently supported This is both true and not. 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. ---
**Author:** ![dadepo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/dadepo/32/3667_2.png) [@dadepo](https://discuss.ipfs.tech/u/dadepo)\ **Post date:** [June 28, 2020, 11:08am UTC](https://discuss.ipfs.tech/t/audit-history-log-possible-in-ipfs-ipns/8502/3 "2020-06-28T11:08:25Z")
Thanks @adin for the response… I just have one follow up point of discussion: > [@adin](#): > > 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` ) 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. I mean: Time T1 → IPNS publish --key=`Key` `Path` → `Signed Record T1` of Key to Path Time T2 → IPNS publish --key=`Key` `NewPath` → `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? Or i am getting how IPNS work wrong? ---
**Author:** ![adin](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/adin/32/2679_2.png) [@adin](https://discuss.ipfs.tech/u/adin)\ **Post date:** [June 28, 2020, 5:51pm UTC](https://discuss.ipfs.tech/t/audit-history-log-possible-in-ipfs-ipns/8502/4 "2020-06-28T17:51:02Z")
@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: 1. Allows me to tell people that I have created a new record R2 2. 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.