From spirens-skills
IPNS — mutable pointers on IPFS, keys, publishing, republish interval, and why dnslink is usually what you actually want. Use when a user needs a stable URL pointing at rotating IPFS content, or when debugging slow/missing IPNS resolution.
How this skill is triggered — by the user, by Claude, or both
Slash command
/spirens-skills:ipnsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**You think IPNS is DNS for IPFS.** It's a mutable pointer signed by a
You think IPNS is DNS for IPFS. It's a mutable pointer signed by a libp2p key, published to the DHT (or pubsub). Resolving an IPNS name means querying the DHT for the latest record signed by that key. Publishing means re-signing and re-announcing. Nothing about this is fast.
You think IPNS is fast. First-lookup IPNS resolves via DHT walk — typically 2-30 seconds, sometimes longer, sometimes failing. Kubo caches resolved records, so warm lookups are instant, but every cold client pays the DHT cost. Pubsub IPNS (opt-in) is faster but requires both publisher and resolver to be on the pubsub network.
You forget IPNS records have TTLs. Records last ~24 hours on the DHT by default. If the publisher goes offline and doesn't republish, the record eventually evaporates. Kubo republishes on an interval — set it shorter than the record lifetime.
You use IPNS when dnslink would be better. For anything where you control a DNS domain, dnslink is almost always the right answer — faster resolution, standard DNS tooling, no libp2p key management. IPNS shines when you don't control DNS (purely-onchain apps, personal identities without a domain).
/ipns/k51qzi5uqu5... # public key, base36
/ipns/12D3KooW... # legacy PeerID form
# DNS TXT record at _dnslink.example.com:
"dnslink=/ipfs/bafybei..."
/ipns/example.com paths.Kubo's resolver is already dnslink-aware. A request to /ipns/example.com
triggers a TXT lookup at _dnslink.example.com:
dig +short TXT _dnslink.example.com
# "dnslink=/ipfs/bafybeiabcd..."
Update flow:
/ipns/example.com now resolves to the new CID.For automation: most DNS provider APIs let you PATCH a TXT record. The
same Cloudflare token scoped Zone.DNS:Edit used for ACME can update
dnslink records on the same zone.
# Generate a key.
ipfs key gen --type=ed25519 --size=256 my-site
# Publish (pointing at the current CID of some content you pinned).
ipfs name publish --key=my-site /ipfs/bafybei...
# Resolve.
ipfs name resolve /ipns/k51qzi5...
Kubo republishes your own IPNS records on a schedule:
# Kubo config
Ipns:
RepublishPeriod: "4h" # default "4h", "0" = disabled
RecordLifetime: "24h" # how long the record is valid
Set RepublishPeriod < RecordLifetime so records are always fresh
before expiry. Stop the node, stop republishing — record goes stale and
eventually disappears from DHT caches.
Ipns:
UsePubsub: true
Subscribes to an IPFS pubsub topic per key. When the publisher updates, subscribers hear about it within seconds — no DHT lookup needed. Both sides must have pubsub enabled. Fallback to DHT if the other side doesn't.
The IPFS gateway serves IPNS at:
/ipns/<key-or-domain>/path/
k51qzi5...ipns.example.com/path/ # subdomain form
example.com.ipns.example.com/path/ # dnslink via subdomain
Works for dnslink too — /ipns/example.com on a gateway does a
TXT-record lookup and returns the resolved content. Handy for one-shot
tests.
For /ipns/example.com:
_dnslink.example.com TXT.dnslink=/ipfs/bafy… → resolves to that CID.For /ipns/k51qzi5…:
Step 1 in the IPNS case is the slow one.
ipfs name resolve --nocache /ipns/<key> from your own node — if that fails,
the DHT doesn't have your record.--nocache forces a fresh resolve.Ipns.RecordLifetime. Default
is 24h; 48h-168h is fine for infrequently-updated content.SPIRENS's dweb-proxy layers ENS on top of dnslink: an ENS name's contenthash (or its dnslink fallback) resolves to a CID, which the gateway serves. IPNS is only involved if the ENS record itself points at an IPNS path — rare.
See docs/09-dweb-proxy.md for the
resolution chain (ENS → dnslink → IPFS) and
ens-resolution/SKILL.md for the ENS
specifics.
Provides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub mysticryuujin/spirens --plugin spirens-skills