# Understanding guarantees of the improved IPNS over pubsub

**URL:** <https://discuss.ipfs.tech/t/understanding-guarantees-of-the-improved-ipns-over-pubsub/8713>\
**Category:** Help\
**Tags:** ipns\
**Created:** [July 20, 2020, 2:17pm UTC](https://discuss.ipfs.tech/t/understanding-guarantees-of-the-improved-ipns-over-pubsub/8713 "2020-07-20T14:17:23Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![rick-li](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/rick-li/32/4088_2.png) [@rick-li](https://discuss.ipfs.tech/u/rick-li)\
**Post date:** [August 31, 2020, 12:39am UTC](https://discuss.ipfs.tech/t/understanding-guarantees-of-the-improved-ipns-over-pubsub/8713/12 "2020-08-31T00:39:52Z")

</div>

> [@adin](#):
>
> @rick-li I assume you mean QmHashNew instead of QmHashOld here, right?

Sorry I meant QmHashNew here let me correct it .

> [@adin](#):
>
> As described in the issue below essentially what’s happening is that you’re not searching the network. If you spin up a new node `node3` and have it do `ipfs name resolve QmIPNS` you should get the latest record. Thanks for prompting me to dig into it 😄

Thanks for the explanation, I spinned up a new node and confirmed it can get the new hash.

---

_[View the full topic](https://discuss.ipfs.tech/t/understanding-guarantees-of-the-improved-ipns-over-pubsub/8713)._