I have a doubt related to the lifetime when publishing an IPNS
here says lifetime is the time duration that the record will be valid for. But is not maximum defined in the docs.
In this thread says it has a max of 24 hours and it would be great to confirm it.
And here there is a guy without response of what I am asking too.
So, lifetime is <= 24hs, right? in you want to keep it for more time you must republish it? or there is another workaround?
Little bit context of what we want to accomplish:
We provide a user a way to upload their own data into IPFS, using IPNS (local user ipfs node peer id). The user call an endpoint like /upload/:ipns
We store the IPNS inside our database and pin the IPFS hashes related to the sent IPNS
Use a website to show user data.
We can make the persistence of the IPFS hashes with the pin option, but we can not make the relation between IPNS and IPFS live forever with the 24 hours limit. And it is not something happy to ask the user to keep republishing the IPNS every 24 hours
No, we have not yet implemented delegated publishing of IPNS addresses. The linked thread is a bit long but I recommend reading through it; it thoroughly discusses IPNS timeouts and the related issues.
Yeah, I read it (I think this is the four times haha)
You said:
The 12 hour limitation comes from level 3. In order to be able to publish permanent records, we'd need a some key-value store with actual consistency guarantees (like a blockchain).
I just want to confirm that nowadays it is not possible to make IPNS persistent even with a woraround.
Maybe there is another way to achieve what we want. Just asking, Do you know any way to do it?
This:
Little bit context of what we want to accomplish:
1) We provide a user a way to upload their own data into IPFS, using IPNS (local user ipfs node peer id). The user call an endpoint like /upload/:ipns
2) We store the IPNS inside our database and pin the IPFS hashes related to the sent IPNS
3) Use a website to show user data.
We can make the persistence of the IPFS hashes with the pin option, but we can not make the relation between IPNS and IPFS live forever with the 24 hours limit. And it is not something happy to ask the user to keep republishing the IPNS every 24 hours
Other than have (or pay for) some server to stay online and use your keys to republish, no.
It sounds like you’re building a pinning service that uses IPNS. Unfortunately, I can’t think of a good workaround that uses IPNS (other than to have users share their IPNS keys with you, one can make mulitple). However, you can use something like dnslink. If you add a dnslink=/ipfs/QmFile TXT record to a domain (or the _dnslink subdomain), IPFS will resolve /ipns/mydomain.com to /ipfs/QmFile. However, this relies on the security of DNS (poor).
However, you can use something like dnslink. If you add a dnslink=/ipfs/QmFile TXT record to a domain (or the _dnslink subdomain), IPFS will resolve /ipns/mydomain.com to /ipfs/QmFile. However, this relies on the security of DNS (poor).
But if I have a directory like /files and I need to change one file inside /files, I will need to update the dnslink, right? Even I will need to republish the IPNS every 12 hours
The IPNS will be republished every time a user uploads content through my node. What if nobody uploads anything for say 2 weeks.
Will the IPNS entry still be resolvable via ipfs name resolve <my peer id>localy so that I don’t need to store its target anywhere else?
If yes, does this also hold when the node gets restarted / updated?
Edit: I just observed it takes several seconds to publish IPNS. So that seems not to be the right approach if you want to add uploaded user files concurrently all to the same directory.