Note: still very WIP

What are IPNS and DNSLink?

IPNS stands for InterPlanetary Naming System and is a self-certifying mutable pointer. It achieves this capability by utilizing public and private cryptographic key pairs and having the name of the mutable pointer be securely derived from the public key that can verify the pointer. Since the name of the pointer is tied to how the pointer can be certified it is called “self-certifying”. Those familiar with IPFS will notice a similarity with content-addressing being self-certifying since in that case also the name of the pointer (e.g. CID) is tied to how the pointer can verified (e.g. hashing). This self-certifying nature gives IPNS a number of super-powers not present in consensus systems (DNS, blockchain identifiers, etc.), some notable ones include: mutable link information can come from anywhere, not just a particular service/system, and it is very fast and easy to confirm a link is authentic.

DNSLink is a standard for a mutable pointer system that stores its links in DNS TXT records corresponding to a given domain name.

Technical Baggage

Default performance

• Resolution
  • The time to resolve records in go-ipfs with the default settings can be slow (X seconds)
    • Note: Finding provider records and finding peer addresses in the DHT is must faster basically because you only need to hear useful information from a single peer, whereas IPNS requires hearing from multiple peers such that you are fairly confident you have the “latest” record
  • Enabling either IPNS over PubSub or using the Accelerated DHT Client drastically improves performance here
    • Neither are enabled by default at the moment:
      • Accelerated DHT Client: Basically it requires too many resources to run by default see here, we need more gradual (and controllable) resource usage here
      • IPNS over PubSub: Enable PubSub by default, garbage collect topics, return errors when subscribed to too many topics for PubSub to handle
        • There may also be concerns here around how many pubsub topics/IPNS keys a node could subscribe to
  • Resolution times on systems like the ipfs.io gateways is about as fast as IPFS resolution of uncached content due to the Accelerated DHT Client
• Publishing
  • The issues here are similar to the above, however generally speaking alternative systems (e.g. DNS) take much longer to publish updates than IPNS does
  • Leverage the experimental options above drastically improves performance here as well
    • Some interested in the DHT might want to look at DHT Overview, although at the moment it’s targeted more at building some general understanding and intuition rather than a detailed description

JS Stack Support

• Users trying to use IPNS from JavaScript in web browsers run into a variety of issues here related to how web browsers are isolated from the p2p network due to transport restrictions.
• Generally speaking we get around this by delegating work out to nodes with greater capabilities that are not in web browsers.
  • Completing the implementation of https://github.com/libp2p/js-libp2p/pull/1008 would resolve a lot of issues here since the browser nodes could just ask a Go node running the accelerated DHT client to do resolution for it

No tooling in go-ipfs for IPNS third party republishing

• There is no way for a go-ipfs user to opt into keeping an IPNS record they are not the publisher of alive, which increases the burden on publishers to keep their records alive or for people to run additional tooling on top of go-ipfs
• More info https://github.com/ipfs/go-ipfs/issues/3117

More Issues in ‣

Ecosystem Baggage

• While there are a number of IPFS pinning services, there are no services that will keep your IPNS record alive for you
  • web3.storage is finally building the first one of these
    • PL could offer this service for everyone by leveraging the hydras rather than making people sign up. However, leveraging the hydras in this way is quite brittle and having “magic behind the curtain” leads to user confusion when the magic isn’t quite working. Thankfully web3.storage is planning to build this out properly so we don’t have to do any magic
    • Running this service should be super duper trivial to do and anyone could do it. It’s as simple as running ipfs dht put on a list of records
• The naming/meaning of IPNS is confusing
  • IPNS → InterPlanetary Naming System covers self-certifying naming based on public keys
  • /ipns/someipnskey → an IPNS identifier
  • /ipns/foo.tld → a DNSLink identifier that for historical reasons lives under the /ipns namespace instead of something like /dnslink

Fundamental Issues with Public Key Addressing (e.g. IPNS)