Name (IPNS) Operations | IPFS

Why IPNS exists: a CID is a hash of content — it changes every time the content changes. IPNS gives you a stable name (backed by a keypair) that can be re-published to point at a new CID, so downstream consumers can follow a fixed identifier instead of updating a CID everywhere it's referenced.

publish

Field	Type	Required	Default	Description
`targetPath`	text	✓ Yes	—	Path to publish, e.g. `/ipfs/<cid>`.
`keyName`	text	No	`self`	Local IPNS key to publish under — must already exist (see Key Operations).
`resolve`	bool	No	`true`	Check that `targetPath` resolves before publishing.
`lifetime`	text	No	`24h`	Record expiry duration.
`ttl`	text	No	—	Suggested resolver cache TTL hint.
`v1compat`	bool	No	`true`	Produce a record readable by both IPNS v1 and v2 resolvers.
`allowOffline`	bool	No	`false`	Allow publishing while the daemon has no network peers.
`sequence`	int	No	—	Manual sequence-number override (advanced/rare).

Missing targetPath → CFG_MISSING_TARGET_PATH; blank keyName → CFG_MISSING_KEY_NAME. Response: { ipnsName, targetPath, ttl }.

resolve

Field	Type	Required	Default	Description
`ipnsName`	text	✓ Yes	—	IPNS name or peer ID to resolve.
`recursive`	bool	No	`true`	Follow chained IPNS names to a final `/ipfs/...` path.
`nocache`	bool	No	`false`	Bypass the local resolver cache and force a fresh DHT/network lookup.
`dhtRecordCount`	int	No	—	Minimum matching DHT records required before accepting a result.
`dhtTimeout`	text	No	`5s`	Maximum duration to wait on a DHT-based resolution.

Missing ipnsName → CFG_MISSING_IPNS_NAME. Response: { ipnsName, resolvedPath }.

publish requires an existing key: the keyName you publish under must already exist in the local keystore. The implicit self key (the node's own identity) is always present; anything else must first be created via key/generate.