IPNS - how much is the lifetime

1

when i publish my IPNS site, how long it is online before i need to republish it? 24h? if so, tell me how to make it longer?

2

Yes, after 24h, the DHT wonā€™t broadcast the IPNS anymore. You should republish them every 12h or so. This to prevent outdated records to pollute the DHT for a long time.

3

You can set the lifetime flag to set your IPNS lifetime.

Copying from ipfs name publish --help,

-t, --lifetime string - Time duration that the record will be valid for.
Default: 24h.
This accepts durations such as
ā€œ300sā€, ā€œ1.5hā€ or ā€œ2h45mā€. Valid time units are

                    "ns", "us" (or "Āµs"), "ms", "s", "m", "h".
4

Wondering where you get that help information fromā€¦ Hereā€™s what I get from ipfs name publish --help (go-ifps 0.4.22):

USAGE
  ipfs name publish <ipfs-path> - Publish IPNS names.

  ipfs name publish [--resolve=false] [--lifetime=<lifetime> | -t]
                    [--allow-offline] [--ttl=<ttl>] [--key=<key> | -k]
                    [--quieter | -Q] [--] <ipfs-path>

  IPNS is a PKI namespace, where names are the hashes of public keys, and
  the private key enables publishing new (signed) values. In both publish
  and resolve, the default name used is the node's own PeerID,
  which is the hash of its public key.

  For more information about each command, use:
  'ipfs name publish <subcmd> --help'

No explanation of the parameters. I have been wondering for a while what the difference between lifetime and ttl is, and how each of these parameters affect the availability of a published definition.

5

I am surprised by the difference with the help flag. I have go-ipfs 0.4.22 as well.Hereā€™s what I see when I type ipfs name publish --help:

ipfs name publish --help
USAGE
ipfs name publish - Publish IPNS names.

SYNOPSIS
ipfs name publish [ā€“resolve=false] [ā€“lifetime= | -t]
[ā€“allow-offline] [ā€“ttl=] [ā€“key= | -k]
[ā€“quieter | -Q] [ā€“]

ARGUMENTS

  • ipfs path of the object to be published.

OPTIONS

ā€“resolve bool - Check if the given path can be resolved before
publishing. Default: true.
-t, --lifetime string - Time duration that the record will be valid for.
Default: 24h.
This accepts durations such as
ā€œ300sā€, ā€œ1.5hā€ or ā€œ2h45mā€. Valid time units are

                        "ns", "us" (or "Āµs"), "ms", "s", "m", "h".

ā€“allow-offline bool - When offline, save the IPNS record to the the local
datastore without broadcasting to the network
instead of simply failing.
ā€“ttl string - Time duration this record should be cached for.
Uses the same syntax as the lifetime option.
(caution: experimental).
-k, --key string - Name of the key to be used or a valid PeerID, as
listed by ā€˜ipfs key list -lā€™. Default: self.
-Q, --quieter bool - Write only final hash.

DESCRIPTION

IPNS is a PKI namespace, where names are the hashes of public keys, and
the private key enables publishing new (signed) values. In both publish
and resolve, the default name used is the nodeā€™s own PeerID,
which is the hash of its public key.

You can use the ā€˜ipfs keyā€™ commands to list and generate more names and their
respective keys.

Examples:

Publish an with your default name:

> ipfs name publish /ipfs/QmatmE9msSfkKxoffpHwNLNKgwZG8eT9Bud6YoPab52vpy
Published to QmbCMUZw6JFeZ7Wp9jkzbye3Fzp2GGcPgC3nmeUjfVF87n: /ipfs/QmatmE9msSfkKxoffpHwNLNKgwZG8eT9Bud6YoPab52vpy

Publish an with another name, added by an ā€˜ipfs keyā€™ command:

> ipfs key gen --type=rsa --size=2048 mykey
> ipfs name publish --key=mykey /ipfs/QmatmE9msSfkKxoffpHwNLNKgwZG8eT9Bud6YoPab52vpy
Published to QmSrPmbaUKA3ZodhzPWZnpFgcPMFWF4QsxXbkWfEptTBJd: /ipfs/QmatmE9msSfkKxoffpHwNLNKgwZG8eT9Bud6YoPab52vpy

Alternatively, publish an using a valid PeerID (as listed by
ā€˜ipfs key list -lā€™):

ipfs name publish --key=QmbCMUZw6JFeZ7Wp9jkzbye3Fzp2GGcPgC3nmeUjfVF87n /ipfs/QmatmE9msSfkKxoffpHwNLNKgwZG8eT9Bud6YoPab52vpy
Published to QmbCMUZw6JFeZ7Wp9jkzbye3Fzp2GGcPgC3nmeUjfVF87n: /ipfs/QmatmE9msSfkKxoffpHwNLNKgwZG8eT9Bud6YoPab52vpy

6

Weird! I tried the exact same command on a virtual server running Debian 9 with go-ipfs 0.4.22, and I got the long output that you showed. But on my MacBook (macOS 10.14 with go-ipfs 0.4.22), I get the short version that I posted.

Back to the main topic, after seeing the long form, I still donā€™t understand what exactly --lifetime and --ttl do, nor how I can use them to get the result that I want, which is typically a name valid indefinitely, i.e. until I assign a new hash to it.

7

I checked the source on this.

TTL is the expire time for a peerā€™s local cache so it specifies how long each peer will keep an IPNS record before checking back with the DHT.

When resolving an IPNS request, a peer first checks its cache. If the record is there and TTL has not expired, it returns the record. Otherwise it fetches from the DHT.

It looks like when TTL expires, it just dumps it from the cache (no eviction callback on creating the cache).

Personally Iā€™d like to see this behavior for ResolveAsync when thereā€™s a cache entry with expired TTL but lifetime has not yet expired:

  1. send the cache entry
  2. fetch from DHT, cache that, and send it

As it is, if TTL expires, you can expect to wait a long time to fetch the latest from the DHT, even if it hasnā€™t actually changed.

1 Like