.ipns

Libp2p keys are long, very long. Even with base58 encoding they are not at all human-friendly. It is therefore often necessary to map the key to a human-friendly name. And here comes DNSLink, where you link your domain name with a libp2p-key. Leasing a domain name however costs money. Renewals are even more expensive. And you are always at a bind about which domain name registrar or DNS provider is the best. Won't it be awesome to have both cost and worry-free names for your libp2p-keys! Compare the situation with SSL certificates. They are so expensive. Then came Let's Encrypt and the world became a better place. As regards domain names, .ipns aims to do the same - make internet free.

Table of Contents

• .ipns
  • Declaration of Authority
  • How registration works
  • Decentralized registry
  • Resolving .ipns names
  • Status

Declaration of Authority

Centralization gives you simplicity at the cost of trust. For a very young project however, simplicity is way more precious than the lofty ideal of decentralization. Hence we won't talk of ENS and decentralized domains just yet. But we'd make our way to there one day, may be soon enough.

With this premise, let this repository be the central authority for registering and maintaining this newly proposed .ipns name-system.

How registration works

1. Expose your webapp/website with ipns-link, providing it with your chosen .ipns domain name.
2. Go to the registry portal (under construction) and submit the domain name and the libp2p-key.
3. The portal checks the name field in your ipns-link-posted Manifest for the presence of the provided domain name. If matched, the portal puts your domain, libp2p-key, registration timestamp, QR-req-count in the registry and provides you with a QR code generated from that data with a secret salt known only to the portal + the QR-regain-count. You just have to scan the QR with a Google-authenticator or similar app in your phone.
4. The portal periodically publishes the current registry over IPNS under a well-known libp2p-key which may be DNSLinked for convenience. Other nodes like the ipns-link origin-servers and gateways can simply cache the registry and republish periodically. All this is done automatically and the user doesn't need to configure anything for this.
5. To add a subdomain, you simply need to repeat step 1, and then step 2. This time however, you also need to provide the portal with the TOTP generated by the Google Authenticator.
6. The portal first checks the domain name corresponding to the requested subdomain and recomputes the original QR code, it gave you during domain registration. Then matches the provided TOTP against it. On match it performs step 3 and 4 for the subdomain instead of the domain.
7. This means, you can only register a subdomain if you own the corresponding domain.
8. Domain names are valid for 11 months. So you need to renew it. In order to renew, you need to provide the TOTP to the portal.
9. If not renewed, the domain will expire and not available for registration for a grace period of 1 month. You can still renew within this period. To expire a domain, the portal simply removes its mapped libp2p-key from the registry. So, to renew within the grace period, you also need to provide your libp2p-key along with the TOTP.
10. If not renewed within the grace period, the domain is simply taken off the registry which means its available for fresh registration.
11. The registration process keeps you anonymous. No email id is required. This should also mean that you have to keep the QR code safe as, in case you lose it, you would lose the ability to renew your domain or create a subdomain. But that is so inconvenient. Also in case your QR code is stolen, you'd need a way to request a new QR. To request a new QR code, you wont need to provide any TOTP. Instead, the portal would provide you with a nonce, that you must put into ipns-link which then puts it in the nonce field of the manifest. You then simply click verify in the portal and upon validation you are given the new QR code. This code is generated simply by incrementing the QR-req-count in the registry.

Decentralized registry

The registrar is centralized. But not the registry. The registry is hosted on IPFS/IPNS. Gateways and other nodes cache the registry and republish the IPNS records.

.ipns names are free. But they are not recognized by DNS, ICANN or the browsers. These names are only meant to be used with IPFS and IPNS-Link Gateways and anyone using IPFS. Once a user exposes a site with IPNS-Link or IPFS+IPNS, and she has a .ipns name of her choice registered that points to the IPFS/IPNS path to her site, any gateway should be able to resolve the path /ipns/her.chosen.name.ipns. Or, her website visitors, can simply go to https://her-chosen-name.ipns.gateway.tld.

Resolving .ipns names

IPNS-Link-Gateways would always know how to resolve .ipns names. But IPFS gateways aren't aware of this domain. May be in future they would be.

Using a browser extension like Requestly, users can redirect all URL's containing *.ipns to an IPNS-Link-Gateway. Then, simply typing <subdomain>.<domain>.ipns in the browser would do.

Status

WORK-IN-PROGRESS. Follow the IPNS-Link project to remain updated.