Interesting, thanks for sharing.
The UX challenge in my version is definitely real, but let's explore it a bit. I originally had the idea of "pinning" so that any UX pain due to disambiguation could be minimized to the first visit, but perhaps even that could be significantly improved. In a Nostr setting, the popularity rank could be scoped to the relay. Community-centric popularity rankings (i.e. having your client sample from its favorite relays) could have nice advantages, and at the same time mitigate that centralization danger. Clients could automate disambiguation in many cases to minimize UX pain (and should lock-in so users don't get unsuspectingly surprised by a different same-named domain on a future visit). UX/UI would definitely have to be in focus.
Such a radically new paradigm as non-unique names would have costs / trade-offs. Perhaps the best middle ground would be for clients to forever support both ends of the spectrum (traditional DNS and non-unique naming). The advantages of trad DNS would remain, while a non-unique naming system would provide an escape valve to discourage from and protect against power structures abusing the more authoritative DNS system. Relays could even inform their own ranking based on the existing DNS system for seamless transition. That is to say, if I control a mysite.com registration in both trad DNS and on the Bitcoin blockchain, then I would keep both up-to-date. If a divergence happens, the hybrid system would seamlessly failover to the non-unique naming system, still pointing clients to my intended site. This would also facilitate a painless transition from trad DNS to non-unique naming without any ugly UX disambiguation for text-book cases. In cases where no such authoritative link exists (such as brand-new Bitcoin-only registrations), your "first come, first served" approach could be applied as policy, not requirement. This would relegate manual disambiguation to an available option / feature, rather than making it an obstacle to acceptance.
In that sense, the "non-unique" part (of this newly coined term "non-unique naming") would serve mainly as the relief valve, but would not get in anybody's way. Spoofs of google.com would never bother anyone because they would have to be sought out. First-time registrations would have priority, but squatters could still be circumvented with community support through manual disambiguation until relays quickly get the hint and switch over to the more popular site.
What's nice is that we can define the protocol for establishing names on the Bitcoin blockchain, and name conflicts will have to be handled somehow. So if it gained any traction at all, some convention for handling naming conflicts would necessarily arise. Whether it's your idea, my idea, or something we haven't thought of yet.
reply