no IPNS pinning service?
Because no one made one yet.
This is a feature we want, no one got around doing it yet.
web3.storage works on a similar feature I belive.
Will a node republish automatically (as implied by the
Ipns.RepublishPeriodconfig setting) or will I need a cron job for that?
Your node will republish automatically as long as it runs.
[…] the fact that publishing IPNS records from more than one node is unsupported behavior and so occasionally runs into weird corner cases.
The main issue is that if your have multiple nodes publishing IPNS records they will fight over themself and have nonce colisions.
IPNS records have a “Nonce: Natural-Number” field. In theory it is simple, each new record is the previous one plus something non 0.
The DHT have an issue, it is likely there can be multiple state of an IPNS in flight at any time.
Let’s assume you found two records:
Key: k111
Path: Qmfoo
Nonce: 100
Key: k111
Path: Qmbar
Nonce: 200
Both one have the same key k111 however they point to different CIDs, Qmfoo and Qmbar.
Then you just lookup the nonce and the biggest one is said to be valid, so in this case Qmbar is what IPFS will show you.
However this nonce counter is local to a node.
If you have two nodes publishing under the same key, the first one can publish using nonce 100 and the second one, unaware that the first one already used 100, will also use nonce 100.
Giving you this situation:
Key: k111
Path: Qmfoo
Nonce: 100
Key: k111
Path: Qmbar
Nonce: 100
And then you are fucked, because you can’t know which one is the newest one.
I don’t know what IPFS does in this case, there are three possibilities:
- The second node DHT publish fails because the DHT nodes hosting the record knows they already have a record with nonce.
- The second node DHT publish succeed because due to usual DHT churn some nodes doesn’t know about the first record and thus accepts the second record.
- Then while searching it fails.
- Or while searching IPFS returns the first one it finds (making it essentially random as which one you will land depend on PING and DHT randomness).
I then see that in cloudflare’s IPFS gateway guide IPNS is not mentioned at all. Only dnslink. I’ve also read rumblings here and there that IPNS is best avoided, but not clearly why.
IPNS doesn’t work well, it require a single node to stay online and republish else they go offline.
They have bad or atrocious propagation time if you don’t use pubsub.
For now, IPNS is more a beta / alpha feature, dnslink work.
While something like pinata can pin IPFS hashes, there apparently is no service that can “pin” IPNS records.
That a whole other question.
So there is an ambiguity when we talk about “IPNS pinning”.
To me and the way we use this in IPFS issues / discussion, mean “pinning and republishing the IPNS record, it is a 300Bytes ~ 3KiB piece of data, that give you the public key, the nonce, the expiry and the path you need to follow”.
It seems the feature you ask is more “IPNS following”, where pinata would download new content and pin it when they see a new IPNS key.
From a pinning point of view thoses are really different.
IPNS following would require pinata to periodically check the key, and maybe download lots of data often when you update your key.
This feature can be done with a cron job and a 5 lines bash script, it is then less priority, because republishing of IPNS record is something you can’t fix outside of IPFS (unlike follow).
I’d like to create a web-based CMS based on IPFS. I was thinking of running IPFS in the browser and creating an IPNS key and storing it in localStorage with a dialog to export/import the key so it can be stored in a password manager or browser extension.
Seems a perfectly good idea to me.
But since IPFS in browsers have very limited (essentially no) access to the IPFS network.
You would need a server somewhere (a local IPFS node, web3.storage, …) to relay your IPNS records, that something we would like to able to do, just no one coded it yet.