docs: upgrade 1. (ref slack thread) #88
Conversation
| 2. IPNS is very modular. You have a record that is signed and points to an immutable record. You can use IPNS over DHT, or pubsub, as discussed, but there are also other implementations (see Namecoin, or ETH.link). | ||
| **Q: The IPNS links are not decentralised and are easy to censor - are you working on a solution?** | ||
|
|
||
| A: IPNS is a modular name system. In its pure form, it is a record that is signed and that has an immutable pointer (CID). You can use IPNS over DHT, or pubsub, as discussed, but there are also other implementations (see Namecoin, or ETH.link). |
There was a problem hiding this comment.
Namecoin and ETH.Link don't use IPNS do they? I haven't interacted with them but I thought they were DNS implementations that DNSLink can use.
There was a problem hiding this comment.
AFAIU, you can use /ipns/<namecoin||eth.link> and get stuff resolved, correct?
There was a problem hiding this comment.
Right, but I think that's just because for historical reasons DNSLink uses /ipns/ipfs.io instead of something like /dnslink/ipfs.io. I think namecoin and ENS both just use DNS resolvers
There was a problem hiding this comment.
@aschmahmann AFAIU, IPNS was supposed to be a multi-namesystem. If that is not the case, we can always say that rather than using IPNS, IPFS implementations can also use other resolvers, although not part of the protocol.
There was a problem hiding this comment.
IPFS implementations can also use other resolvers, although not part of the protocol.
Sure we can say that as an overarching statement since IPFS and IPNS are not the same thing. However, "IPFS implementations" is an under-defined concept. For example, must every IPFS implementation include any of a DHT, Bitswap, UnixFS-support, libp2p peerIDs, or an IPNS resolver?
Regard IPNS the TLDR is that IPNS documentation is bizarre since we both define what an IPNS record is and IPNS propagation systems (DHT + PubSub) as well as use /ipns/dns-address.com for things like DNSLink. This feels similar to how we used to use /ipfs/QmXyz for peerIDs for historical reasons, but since it makes no sense we now use /p2p/QmXyz.
@daviddias I have not seen any documentation on what IPNS is that explains what all the different resolvers are and how they interoperate. My understanding is:
IPNS: It has a record type and a spec
DNSLink: It has a spec
Proquints: They have a spec (I've never seen anyone examples on our docs site for this nor any links on our docs site to tools for generating proquints, but it's supported in the code)
Namesys (or the only seen in code "MPNS"): It is an interface that (recursively) resolves one path into another using a set of registered resolvers (e.g. /ipns/ipfs.io -> /ipns/bafyabc -> /ipns/bikad-fokor-zihoj-bajir -> /ipns/myexample.com -> /ipfs/bafyxyz)
It's quite confusing that go-ipfs Namesys, as far as I know, insists that all resolvers have the /ipns prefix and that we implicitly figure out which resolver to use (e.g. do you look like a public key use IPNS, do you look like a domain use DNSLink, do you look like a proquint use proquint). However, my understanding was that the plan was to modify this so that new resolvers would be valid (e.g. /foo/qazwsx -> /ipns/bafyabc -> /bar/123 -> /ipfs/bafyxyz).
There was a problem hiding this comment.
@daviddias If you're interested in this I'd look at ipfs/specs#198 (comment), or that whole thread generally, but that's not a prerequisite for the answer here at all as much as a reminder that we need to make some terminology/docs decisions as well as some related technical decisions.
There was a problem hiding this comment.
For the purposes of this Q&A, I think the current answer is fine, just removing the reference to Namecoin and ETH.link and mentioning "other resolvers, external to the protocol" is going to be enough. Even if we had the technical issues resolved, we would not be able to provide all the detail in this Q&A.
Co-authored-by: Adin Schmahmann <[email protected]>
No description provided.