ipns resolving when not connected to the internet

[Faleidel]

Trying to resolve your own ipns id when not connected to the internet does not work.

Shouldn't your ipfs node retrieve the record from cache or understand that its trying to resolve itself?

Similar to #2078

[jbenet]

Shouldn't your ipfs node retrieve the record from cache or understand
that its trying to resolve itself?

yes.

[jbenet]

(though when online, it should still check-- there may be two nodes publishing to the same name. in the future not all names will be the same as the peer-id)

[whyrusleeping]

yeah, this is tricky for the reason @jbenet mentions in his second comment. If your node is 'online', meaning the daemon is running and you could potentially connect to peers (even if just on your LAN), your node will try to find the most up to date version of the record. When we allow multiple peers to publish to the same namespace, this will be very important to have. Cases like this need to be well thought out

[Faleidel]

@whyrusleeping My use is of using ipns as a local storage for the state of my webapp. But if getting that data back always search to see if other nodes have a more up to date version of the record then am I stuck with this 1~2 second wait?

Or will there be an other way to do this?

@fazo96 aren't you on a similar situation? What is your take on this?

[Kubuxu]

I think in case of IPNS two stage cache would be beneficial.
The cache would work as follows (time variables are up to discussion):
1st stage would contain entries that were just received (1 to 5minutes ago) and they would just be returned
2nd stage would contain older entries (up to for example 30mins old) and they would be used in case of request but at the same time search for new entries would be started.

This way user won't feel that cache expired (you can feel it for example on my site) which happens from time to time even though you are reloading site all the time. Also local IPNS entries could reside in 2nd stage (local entry will be updated in case that newer is found).

One disadvantage is that user might get older than he suspects entry but IMHO it is better than ~10s delay (it is better in 0.4 but still really noticeable).

[whyrusleeping]

@Kubuxu I agree for the most part. But @jbenet has said that ipns should never return an old entry (or at least, thats the impression I've gotten so far).

@jbenet correct me if i'm wrong here. What do you think we should do here?

[fazo96]

@Faleidel yes I've encountered this problem, for now my app doesn't have a solution but I plan on resolving the local IPNS name to the hash of an object contained in MFS (the Files API) at the application level and then keeping it published automatically. This assumes only one entity publishing to an address of course.

This problem is very tricky to solve right: on one hand it's better to resolve to an old record than nothing at all, on the other hand this hurts some use cases where having the latest data is more important.

There could be a flag in the resolve command that tells IPFS to find a record as fast as it can without checking wether it's outdated. Then we can use this at the application level to return some data knowing that it might be old, while we try to get the latest at the same time.

[jbenet]

• SOME types of IPNS records MAY allow readers to use old entries, or MAY have no concept of expiration at all.
• The current IPNS records have a strict TTL, after which they ARE NOT valid and MUST NOT be used. Think of them like DNS records.
• Other IPNS record types will come when IPNS is improved after IPLD merges into master.

This problem is very tricky to solve right: on one hand it's better to resolve to an old record than nothing at all, on the other hand this hurts some use cases where having the latest data is more important.

And this is why the creator (will be able to) chooses the type of record. you should be able to do either without ambiguity.

There could be a flag in the resolve command that tells IPFS to find a record as fast as it can without checking wether it's outdated. Then we can use this at the application level to return some data knowing that it might be old, while we try to get the latest at the same time.

opposed to that, we need to be very strict about what constitutes an expired entry. if it's expired it MUST NOT be used-- this is critical for security, and for a solid, reliable UX. (imagine if you update your domain's DNS but some rogue dns servers are returning old records because they feel like it, and browsers decide to use them knowing they're old...!!!). records with different semantics will be possible, but the creator needs to be explicit about that.

[fazo96]

@jbenet what you said makes a lot of sense 👍

Sounds like letting the creator choose the rules for its own records is a lot better than having the clients decide what to do.

[magik6k]

Resolving now works offline, when online we still check the network