Thanks for the patient explanation nostr:nprofile1qqsre6jgq6c7r2vzn5cdtju20qq36sn3cer5avc4x8kfru5pzrlr7sqpzpmhxue69uhhxmmvda3k7tnwdshsvcu4cn. Getting a sense of the tradeoffs helps a bit, but I must admit that I still need to give it more thought before I fully grock your system. What do you mean by "no name scarcity"? Can others claim the same name that I have already claimed? I guess the cost of doing a Bitcoin transaction is what rate limits my ability to claim as many names as I want right?
Discussion
A pleasure =3
To further elaborate on what I meant by "no name scarcity", let's look at Space to help deliver what I mean.
You have name.space on the Spaces protocol, where "name" is unique and "space" is the protocol TLD (like .com) let's say.
On DNN, we have name.nABCeAbsurd, where the unique part of this is the TLD/ID (in this example, it's nABCeAbsurd, which is what I got when I did a bitcoin self-transfer. Another's might be nJHDcAbility, for example, or nMDKa12Zoo many years later), and "name" can be whatever you want, even if it's the same as someone else. The unique part is the TLD/ID, not the name.
Aah, so the name is human readable, but the TLD is a large random string - ie. the entropy that makes it secure. That makes sense. Does this mean I need to check the large random string like checking an npub to make sure I'm being redirected to the right IP address?
Are you familiar with zookos triangle?
When trying to understand new systems, I like to try to place them on that triangle to reason about the tradeoffs...
It seems to me like DNN has the same set of tradeoffs as noDNS, but DNN has a global state thanks to Bitcoin. Where does DNN store the IP address that a name resolves to? Does it use nostr for this? Apologies if you already explained this..