IPNS publishing guidance for high availability

[markg85]

@danieln

@markg85

To replicate:

• Spin up an IPFS node.
• ipfs name publish something, but remember it’s CID.
• shut down this IPFS node
• Resolve works during TTL time (so for 48 hours it “seems” like all is fine)
• After TLL expires (aka, 48 hours + 1 nanosecond): No more resolve

In this example what was the TTL set to? How do you attempt to resolve the name (if you shut down the node)? Using a gateway?

Your reproduction can be recreated with a TTL set to 1 minute, at the cost of resolution being a bit slower after the first time. The most important field is the lifetime, which defaults to 48 hours in Kubo. Meaning the record is valid for as long as nodes keep it around for.

The defaults!

And resolving was, in the past, just using your browser with ipns://<cid> or the gateway version of that.

This might sound like a weird compliment (or insult ) but you know too much about kubo and it’s commands. Assume the defaults unless explicitly specified otherwise.

@danieln

Delegated routing only re-publishes the record. It can’t update the TTL without the private key, as the TTL is signed. The idea is that you can set the lifetime of a record to however long you want to allow delegated republishing, and then republish the record (using a cron job, gh action or whatever) with an HTTP request to the delegated routing endpoint.

Oh… my… So i never used delegated routing and didn’t know how you’d make use of it. If was too late for my use with IPFS. But let’s reasons this a little to see why this doesn’t help.

• Starting point, filled with assumptions. The root cause of this whole IPFS not being able to be resolved is the node with the private key not being online in time to refresh the TTL. Now if this is a TTL in the record itself or a TTL in the DHT or for al i care called a quartz crystal vibration counter mechanism… Some time unit somewhere expires and causes the dreaded issue of ipns not being able to be resolved…
• If a node is having trouble being online, say because it’s on the users laptop.
• then a cronjob in the same fashion will fail too
• thus the user needs to setup some third party - always online - resource (a VPS or whatever)
• on this always online resource (this costs money, could be a $5 VPS node, let’s assume it is) the user now has to configure some scripts (cron itself, the script to call and how to interact with delegated routing)
• How does this make any sense? Why doesn’t the user just run an IPFS instance on that always online VPS and does IPNS from there. Problem solved.
• On the contrary, if this additional config is required anyhow then why not go for something less vague and freaking use a key/value store in which you “publish” your last IPFS CID. At this point that’s hardly more work then to keep your IPNS record breathing.

I’m sure delegated routing has benefits beyond IPNS! But in this IPNS case it’s value seems suspiciously low to non existent.

I think we’re done discussing the semantics and technical details of why IPNS fails so easily. We’re not even clear on the property that determines it’s ability to resolve. I say it’s the TTL in some shape or form. You keep it in the middle and open to interpretation with a word jungle of different time units. I don’t believe the validity field has anything to do with this root cause (not being able to resolve). I could well be wrong but history and bug reports have always hinted at the TTL, not at validity.

One of the answers should be easy to figure out. If you do ipfs name publish to a CID that is widely hosted. Now shut down the node on which you did the publish. Use delegated routing exclusively for that ipns record. Does that record still resolve after a couple days? If it does then it at least tells you if delegated routing is even suitable in this scenario.