How do I make my IPNS records live longer?

[lidel]

@danieln

• lifetime to 7 days
• TTL to 10 minutes

1. You publish the IPNS record and then shut down your IPFS node.
2. You try to resolve the IPNS record 3 days later via a public gateway, a long as the DHT nodes that you wrote the IPNS record two are still up, you will be able to resolve the IPNS record.

iirc DHT nodes will drop stored values after ~24h, no matter what Lifetime and TTL you set.
Someone needs to keep reproviding your signed IPNS record every day, or it will be “forgotten” by the DHT.

Tip: if you enable Ipns.UsePubsub then DHT limitation is lifted, and you can fully benefit from longer Lifetime: other peers who are following the same IPNS name can send you a valid, signed IPNS record, even if it is no longer available on DHT (see Layering persistence onto libp2p PubSub).

@danieln

Am I understanding the two values (lifetime and TTL) correctly? If so, what’s the tradeoff for setting a high lifetime value?

Mostly correct. The caveat is that DHT is dropping records older than 1 day, and Kubo nodes are not re-providing third party signed records on DHT, only on PubSub, but that is not enabled by default.

In case of Kubo IPFS implementation, IPNS things you can adjust are:

• Lifetime (ipfs name publish --lifetime, or the global Ipns.RecordLifetime)
  Controls how long a singed IPNS record is valid (how long, in theory, a third-party service or peer without a private key can re-publish it on your behalf to keep it alive).
• TTL (ipfs name publish --ttl)
  Controls for how long IPNS resolver can cache a record before trying to resolve it again (to check if there is a new version).
• Ipns.RepublishPeriod
  (iirc) Controls how often your node will bump Sequence and publish new signed IPNS record. It is ow enough to account for network churn and DHT “forgetting” records older than 24h.
• Ipns.UsePubsub
  Disabled by default in Kubo (tracking issue), but enabling it is a good idea if you plan to publish IPNS records with long Lifetime.

@danieln

since the IPNS record that is distributed is signed, doesn’t that mean that you could theoretically build a service that just observes and republishes a given [public] IPNS key, i.e., the hash of a public key?

Correct.

We don’t have “IPNS Pinning Services” yet, but someone could create one. A service that periodically resolves IPNS name via DHT and listens on IPNS pubsub channel and then re-provides long-Lifetime records on both. This “IPNS keepalive” can be done in “trustless” manner, without revealing private keys to the service.

Some relevant work I am aware of :

• [OPEN GRANT] Fierro IPNS Pinning Service by mrodriguez3313 · Pull Request #142 · ipfs/devgrants · GitHub
• GitHub - web3-storage/w3name: IPNS client and service for generating, updating, and tracking immutable names with signed updates