There seems to be some confusion in general about IPN. You might find this recent thread helpful How do I make my IPNS records live longer? - #10 by danieln
I find the use of the term pinning for IPNS confusing since there already is a term pinning that does something different.
I believe IPNS over the DHT is discouraged but pubsub works quite well.
It seems like there are a lot of separate things being proposed all under the same heading of “better IPNS”
Does it, though?
I’m not talking about the underlying technical details. Those are (and should be) largely irrelevant to the people using a solution. In the “IPFS space”, the concept of “pinning” is basically to make data permanent either via a third party service and/or your own node, at a level of redundancy that you get to decide by choosing the right pinning service and/or node / network of nodes.
The underlying problem people are struggling with when talking about IPNS pinning is just that: Make mapping permanent, independent of the local node that you used to upload/generate the mapping.
So one is permanence for IPFS, the other is permanence for IPNS.
I get that those would be achieved in very different ways.
But conceptually, they don’t seem so different to me.
So how does one “switch” to pubsub? And if one does so, does DHT IPNS no longer work? I’ve struggled in the past to find documentation that would explain what it would mean to have “IPNS over pubsub” vs “IPNS over DHT”, to which extent they are perhaps mutually exclusive, and how to configure them.
Thanks for that - it is indeed helpful.
But participants there also seem to struggle with understanding configuration and persistence.
While I definitely have not understood everything perfectly yet, to me DHT vs pubvsub just seems like different distribution / dissemination mechanisms - and therefore orthogonal to the question of permanence (also referred to as “pinning” by many other posters in this forum).
And as for the time frames involved: People talk about hours or days. But for IPNS to truly be useful we’d probably have to be in the range of years, perhaps decades, as mapping gets more important the longer lived information really is. And there is no guarantee that original node will be around for that long.
The main problem is that IPNS keys live with the node that create them ATM.
IPNS records are just crypto signed CIDs with extra steps. The keys are what matters. No keys no update.
As for persisting the records themselves, right now IPNS via pubsub with very long lifetime is what you want.
You might also want to save the records offline too.
And as for the time frames involved: People talk about hours or days. But for IPNS to truly be useful we’d probably have to be in the range of years, perhaps decades, as mapping gets more important the longer lived information really is. And there is no guarantee that original node will be around for that long.
How exactly are such long-lived IPNS names (years/decades) useful for permanence? It’s mutable, there’s no guarantee of permanence, I think that’s the point, it was created to emulate the same old problems. If your goal is permanence you should be using IPFS instead.
And does “information” really change?
For example, if I measured the outside temperature to be X°C right now, tomorrow it will still be true that I measured X°C right now. Let’s say I publish this information through IPNS. The IPNS content would more or less represent the “current” outside temperature, not the temperature I measured right now. If someone from outside wanted to link to the temperature of YYYY-MM-DD HH:MM, they should use the corresponding IPFS URI, never the IPNS name.
Another example: if a friend publishes their site with an IPNS name and I want to link to it from a post of my own, I don’t see any reason to use the IPNS URI other than the (slim) hope that they might significantly update the post in the future. For permanence, I should use the IPFS URI instead (and pin it myself too).
By using IPNS you’re putting the “responsibility” of permanence on the other side. You have to cross your fingers and hope that they keep all their URIs up and running for eternity. This is exactly why IPFS was created.
EDIT: otherwise I agree with the IPNS related usability concerns previously mentioned in this thread.
Yes
Nothing is permanent. I think a better definition of pinning is simply to protect a resource from GC. The term is slightly overloaded now that there is a remote pinning service api but not overly so in my opinion since it’s exactly what it says “remote”. It’s just pinning but on someone else’s node.
Putting the technical details aside, I’m still not sure what you’re proposing with IPNS pinning other than making it permanent.
Permanent is immutable which is the opposite of what IPNS is unless you’re thinking of some other idea of permanence like availability.
There are a couple of experimental config options to enable it https://github.com/ipfs/kubo/blob/master/docs/experimental-features.md
It doesn’t disable DHT publishing but augments it. I don’t know the exact details but I believe that it will initially use both and then updates are made via pubsub.
It does seem to be a source of a great deal of confusion. It’s unfortunate because I’ve heard IPNS over DHT to be basically unusable but IPNS pubsub works quite well but is still listed as experimental. This causes the belief that IPNS doesn’t work to persist. This probably hurts adoption since the initial impression is a system that is fundamentally broken.
As far as I can tell the problem is that DHT nodes stop reproving after 12 hrs regardless of what the ttl or lifetime is set for so it needs to be republished which can be done by a node that doesn’t have the private key but isn’t currently being done. I think what people are referring to as IPNS pinning is marking an IPNS record as republish able on a non private key containing node but I could be totally wrong.
What I’d rather see the word pinning applied to IPNS is to pin an IPNS record would be to pin the underlying IPFS record and any subsequent IPFS record after update. ie. pin this any any thing it might refer to in the future.
What would be nice is a pointer in an IPNS record to an IPFS snapshot of the previous record so you could chain back to all previous names.
EDIT: It looks like there were a couple of additional posts to that thread that clarified what I found to be confusing in regards to a possible “pinning service”. The difference between re- provide, 1st and 3ed party republishing. (still lacks a name. Having to describe it as 1st and 3ed party republishing, while accurate, is an awkward way to refer to it)
You can try dWebServices which does IPNS pinning for free
IPNS on Filebase is now available! - Unveiling Names: A Dive into IPNS on Filebase