Large IT migrations always fail miserably when people try to do it in one big bang. I want to avoid that misery and try to break up the problems into smaller pieces. We can work on those without breaking the entire stack that relies on the thing we're replacing.
quoting naddr1qq…shxdAahh... Domain Names... As much of a shitcoin that it is, we still need it, for a while at least. I recently had a talk with @Freakoverse where we dove into his Decentralized Naming Network project, or DNN for short. During our talk I made a quick sketch that I think is worth sharing to help shape the discussions around Domain Names and the decentralization of them.
Do we even need domains?
No. Not in the long run. That's my opinion. But we do live in a world where pretty much all interconnected systems rely on it deeply for them to work.
When I had my first job, at a pretty large webshop, I heard many stories about the horrificly large and (almost) unmaintainable monolithic software that ran pretty much everything of the website. Checkout, customer accounts, stock, shipping. A domain nightmare.
The people I worked with there that had transitioned that tech stack into an incredibly scalable (microservice) architecture, well before Kubernetes was ever a thing. The one thing I took away from that is that you can never, ever, EVER(!) replace a complex system in one go if you want to keep it running. You do something smarter, which they referred to as 'The Pac-Man method'.
The way it works is you build a small piece that will live next to the old monolith, and you let it slowly, bit by bit, take over that one task of the monolith. Until you find that the old part is no longer used, then you turn it off. Or... You just ignore it and let it sit.
So why design an alternative to DNS while we have Npub's now? Because we need to pac-man the internet instead of replace it in one go. Every application, every library, every Operating System... The all rely on DNS in one way or another. Meaning that if we want to replace it, we need to leave those pieces in-tact. You cannot expect every app to update to a new fancy solution unless the Upside is massive. And let's be honest, moving to a decentralized domain system isn't as sexy to most people as it might be to us...
So maybe yes. Yes we still need domains, but just for a little while...
Pac-man the domain system, The first ghost
Luckily we have some advantages that come with Nostr, which is that we can split systems that were hard or impossible to split apart before. And I think domains are such a system.
To get to the point. I think domains themselves (the readable something.com ones) are com-plete-ly seperate from the records that live behind them.
I made the argument a while ago already in a NIP proposal (point NIP-97) that previous attempts at solving this always seem to try to include the human-readable part. Which creates massive problems because then suddenly you need to overcome Zooko's triangle (the principle that a naming system can only achieve two out of three properties: human-readable, decentralized, and secure). Impossible, you get yourself into complexity hell.
So... What if we DON'T try to solve for human-readable and just focus on decentralized and secure. That's how I landed at that NIP proposal. What I failed to notice at the time I wrote that NIP is that i included protocols (http/wss) in the 'transport method announcements' as i called them. There was still too much complexity there.
The click came when reading @DNS4SATS.XYZ 's nostr-dns draft. We don't have to redesign dns records. They're fine, and we need them. So let's put them 1-to-1 in nostr events. We just do the identity part, DNS does what it does best, making applications understand their destination.
That's NoDns.
Now we don't need to re-invent the wheel by modifying our OS or rewriting applications. It just works.
Human-readable names
\ So with NoDns we can resolve npub1vlqqp7vev2p7fxkv37wdhvwqfuvewc2ewgfk7e9jvhzqf4x7hjjqch5hcr (npub1vlq…5hcr).nostr and get a fully functioning website. However, that's a slightly hard to pronounce domain.
BUT, we fix that separately now. Because all we now still need is a fancy domain.com to resolve to an NPUB, because that's where we have access to the records already.
The challenge here is there are only two ways of guaranteeing unique-ness.
You appoint an authority that guards that everyone respects the same owner of a name. This is the system we have now
You rely on a global consensus mechanism. That's a blockchain, and there's only one reliable one and that's Bitcoin
If you're reading this you'll know that i'm not too fond of option 1. That leaves us with option two. And @Freakoverse worked on just that. Creating (more or less) human readable domain names using the Bitcoin Blockchain. I think this solution is great to get short domain names that humans can read out. But, it does not allow for fully custom domain names unfortunately.
There's more...
There's a third option though: We ignore uniqueness. Why can't there be 2 wendys.com's? Just like how there are multiple businesses with the same name in the pysical world.
Won't people be confused, you ask? Maybe, like with wendy's in Belgium. But if you're a proper fries-loving Belgium citizen, your browser would resolve to the friendly Snack-bar owner's server because he's closer in your Web of Trust, because your friends and family have been there before and know that the belgium Snack-bar is indeed really Wendy's.
But jokes aside, more likely than not, your domain name can perfectly well exist on the other side of the world without you noticing, or caring. It's a social problem to solve and there will never be a perfect answer, there can be conflict like Wendy's but it will be rare. And the solution is decentralized, everyone picks their own winner.
The only risk? Abuse. So security is a concern. If someone infiltrates your network and claims the same domain, people might be misled to resolve to their npub. I believe that can be mitigated quite well, through PoW, resolving once and saving that state. Encryption to that npub, etc...
The second ghost, https (Certificates)
Because our focus here is on domains, i'll keep it short. But https (certificates) is an important part of how we communicate online nowadays. But it's just as tainted with centralization as Domains, arguably even more so.
How do we attack this ghost? In the same way wo do that for domains works, we self-publish. I recommend to read up more on how NoDns works if you're curious about this.
The third ghost, IP's
The third ghost, IP addresses. Even though the web is VERY resillient, we're still beholden to the use of IP addresses. IP addresses are hierarchical, which I believe to be problematic. It makes it very difficult to connect to peers on a network that constantly changes shape.
People have worked on alternatives that run on the lower levels of our stack but those haven't really taken off yet. Why? I'm currently researching this but I think it's often because the solutions there need some pac-manning too. But we'll get into that another time.
Resolution
Until a fully keypair driven internet is a reality, I believe we will need some smart hacks to transition our way to that. I think it's key that we remove centralized parties from the equation first, before we try to overhaul all software we know and use today. It just doesn't work that way.
Keep chopping up problems into smaller parts, and then:
Bon Apetit