Offline ipns record lives for 1m only

[kpp]

Version information:

go-ipfs version: 0.4.22-
Repo version: 7
System version: amd64/linux
Golang version: go1.12.7

Description:

Start ipfs daemon with a default config, call ipfs cat /ipns... to resolve & cache the content, turn off the internet connection.
The /ipns/ link will be available on the local machine for 1 minute only. After that minute you will not be able to neither cat nor resolve the link by /ipns path (Error: failed to find any peer in table), however the data is still available through a resolved and cached /ipfs/hash.

[bonedaddy]

That's due to https://github.com/ipfs/go-ipfs/blob/master/namesys/namesys.go#L51 and this boolean check being reversed https://github.com/ipfs/go-ipfs/blob/master/namesys/namesys.go#L194

[kpp]

Nice!

[kpp]

Should I use ipfs name publish with --lifetime or with --ttl? Will ipfs name publish overwrite the existent key on other nodes even if the key is cached if they got connection to the publisher?

[Stebalien]

This is working as intended. If the node is offline, we have no way to know if the IPNS record is up-to-date so we return an error after the TTL expires. Note: The TTL is not the same as the EOL. The EOL is when the record is no longer valid, the TTL is how long we keep the record before we go to the network to look for a new one.

Now, that doesn't mean this current model is necessarily correct. We really need to better support offline/local IPNS. However, we need to communicate how "fresh" the response is to the user.

[bonedaddy]

That seems incredibly inefficient. If the record is going to be around for 24 hours by default why is the daemon being forced to re-resolve the record after only 1 minute?

If the user published it and it's valid for 24 hours by default they shouldn't be searching the network after only 1 minute.

[Stebalien]

1. The EOL is how long the record is "valid". It doesn't mean that it's fresh. The EOL is just there as a cutoff to indicate when the record is so stale it should no longer be considered valid. 2. The TTL is how long we cache the record before trying to find a fresh one. Someone can publish a new record _long_ before the record expires. If we cache records until the EOL, we won't find these new records.

[bonedaddy]

Fair points, but isn't the TTL also defaulted to 24 hours? IPNS resolution takes ages and makes it basically impractical to use for anything. If we were to cache records like this for the duration of their TTL and not for a minute it would go a long ways to improving the usability of IPNS which for all intents and purposes is virtually unusable.

My understanding of TTL was to day "hey if this record has a TTL of 45 minutes, we'll consider it valid for 45 minutes before searching the network".

This setting instead disregards that, and only caches it for 1 min. What's the point of a TTL if we're just caching it for 1 minute?

[Stebalien]

Fair points, but isn't the TTL also defaulted to 24 hours?

The EOL defaults to 24 hours. The TTL defaults to 1 minute.

IPNS resolution takes ages and makes it basically impractical to use for anything

I agree. The TTL was set to 1m when IPNS resolution still only took a few seconds (when the network was <1000 nodes and all nodes were connected to eachother.

What's the point of a TTL if we're just caching it for 1 minute?

s/TTL/EOL.

The EOL limits the amount of time an attacker could withhold a new IPNS record without the user noticing. It also limits the amount of time-travel an attacker can perform on an IPNS record. Without it, an attacker could keep on presenting/publishing an old IPNS record long after newer versions of the record have been published.

OT Notes:

• we should consider changing the default EOL to infinity as most IPNS users don't really care about this.
• Blockchains completely side-step this problem as they remember the entire state. Unfortunately, the DHT tends to forget things.

[kpp]

2. The TTL is how long we cache the record before trying to find a fresh one.

That's fine. However I think #6663 should be reopened

[bonedaddy]

Ok I see what you're saying. In that case, wouldn't it be better to handle the ttl in a Publish request with something like:

	ttl := DefaultResolverCacheTTL
	if setTTL, ok := checkCtxTTL(ctx); ok {
		ttl = setTTL
	}
	ns.cacheSet(peer.IDB58Encode(id), value, ttl)

that way situations like OP's could be avoided

[Stebalien]

That's a bug.

[bonedaddy]

How would that be a bug? If the user overrides the TTL value then this would allow overriding the cached TTL in a way that matches the TTL given when publishing a record

[Stebalien]

I mean, our current handling of TTLs on publish is a bug. We should do what you suggest in #6656 (comment) and use the same TTL on publish as we do on resolve.

However, I'm not sure how this fixes the problem.

[Stebalien]

Closing in favor of ipfs/notes#391.