Rationalé: Why another domain service?

[coolaj86]

What

A domain reseller, decentralized through multiple registrars (such as GoDaddy and eNom) that is specifically designed to make censorship-resistant self-hosting effortless.

Automatable, scriptable, and configurable via simple web, CLI, and API tools.

Domains also available for purchase in DASH at a steep discount (for up to 10 years) to spread adoption (similar to what GoDaddy and NameCheap have done).

Why

Self-hosting is a niche that is very inclusive of the Dash community (ex: MNOs), and the self-hosting community is very inclusive of the cryptocurrency community (ex: Umbrel).

The core of the web lies in DNS: the relationship between IP addresses (servers) and Domain Names (URLs).

DNS is already decentralized. It is an asset, an ally in the fight against tyranny and centralized oppression.

If we make it click-button simple to configure Domains and DNS, we democratize the web.

With automation at the DNS level we will bridge the gap between web 2.0, 3.0, or whatever else comes next.

Furthermore, by offering steep discounts on domain purchases to those who buy with Dash, we widen its userbase, increase adoption, and gain recognition as truly tech-forward - separating DASH and its community as Digital Cash.

From web to email, chat, and verification services, DNS is the core technology that we must integrate with in order to extend the products and services all Internet users are already using, as well as make our own services (i.e. MNOs) more accessible and secure.

Use Cases

See below.

[coolaj86]

Use Case: Decentralize and Secure the Master Nodes

Currently the Master Nodes are susceptible to an entire pipeline of "single point of failure"s.

IP-only Addressing: Domino of Vulnerabilities

Most importantly, they rely on the centralized system of IP addresses, which is extremely politically fragile (e.g. AWS).

As part of that reliance, they're also ineligible for DV TLS Certificates, and IP-only certificates can easily be spoofed - the offending controlling organization can simply re-acquire the IP address.

The entire process is a completely centralized black-box - there's no ability to transfer IP addresses between service providers, verify that the IP address is still controlled by the leasee, nor provide redundancy by using an IP address from another provider.

Domain Name Addressing: Highly Censorship Resistant

In contrast, it's very easy to create very durable and secure registrations simply by using multiple domain names owned by different TLD service providers (ex: .com, .dev, .gop) through different registrars (ex: eNom, OpenSRS) with different name service providers (ex: Digital Ocean, DNSimple), but with records all pointing to the same address.

This is exactly the decentralized resiliency that DNS was designed to have by default, but for which very little tooling exists to utilize it.

If we automate away the difficulty of interfacing with the various service providers, we can have unparalleled censorship resistance.

Note: Switching to to domain name based registration will require a trivial code change - simply restoring the default networking behavior by removing the artificial restriction against domain names - and then checking that each resolution in the address resolution field give the same IP address (differences would indicate tampering, or an in-process configuration change).

[coolaj86]

Use Case: Live Wallets

In order for a Live Wallet to be effective, it must be able to receive TLS-secured webhooks (for payment requests and the like). This can be easily automated with domains, but not with IP addresses.

And since DNS has various mechanisms for describing how/where a client should connect - such as with SRV and SPF Records - it's easy to provide fallbacks for and distinguish between a direct IP-to-IP (P2P) and proxied (e.g. STUN, TURN) connections.

For example, I could have multiple SRV records like this:

Service	Priority	Port	Target
dashwallet	10	443	home-desktop.ajswallet.com
dashwallet	20	443	office-laptop.ajswallet.com
dashwallet	50	8443	proxy-home-desktop.ajswallet.com
dashwallet	60	8443	proxy-office-laptop.ajswallet.com
dashwallet	80	443	digital-ocean.ajswallet.com

Client software could be configured to send a webhook to each in order of preference.

A similar setup could be accomplished with SPF-style records, or at a higher level in the software.

Likewise, users will need a domain at which they can log into their live wallet remotely - as with any web app.

[coolaj86]

Use Case: General Self-Hosting

Anyone who wants to self-host has to go through some sort of domain name related process for each service that they want to self host.

By providing easy-to-use tools for self-hosting we attract the kinds of people who are likely to be interested in "self-hosted" money.

Use Case: Self-Hosting Email

Email is the core communication protocol of the Internet, and all of the details of how to set up a legitimate, verifiable, secure server are well documented and relatively easy to do.

The problem has that many, highly-technical steps related to domain name validation are required in order to do this. For someone who would like to self host their own email, it can be a non-starter.

Yet none of these steps are at all difficult to automate - which is why dozens (hundreds? thousands?) of hosted email services of every kind exist - it's just not profitable for them to cannibalize their SaaS market by giving that automation away for free.

Dash Domains would quite literally be the only domain service to provide tools for expertly automating email domain setup. Although not all of the self-hosters would be interested in Dash, it's a unique opportunity for Dash to own a market that's tightly coupled to its (community) values rather than its (spot price) value.

[coolaj86]

Stepping Stone: .dash TLD (Dash Platform DashNS)

If we're going to have some sort of "web 3" name system, it's going to need a truly functional bridge.

So far none of the other web3 projects have accomplished this - they introduce supply chain vulnerabilities by requiring custom browser plugins and still fail to provide valid TLS.

By using the existing decentralized, censorship-resistant system (and automating away the tedious bits), we could bridge that gap, literally perfectly.

But you can't just go out and do this on a whim - you have to first become a reseller (through GoDaddy or similar), then a self-made registrar (ex: "Dash Domains"), then a registry (.dash TLD owner).