pull down to refresh

10 sats \ 2 replies \ @ursuscamp 30 Jan 2023 \ on: Bitcoin-enabled solution to DNS centralization bitcoin
I have had many similar thoughts recently. I have been discussing this with @lightcoin and on the Nostr telegram.
The thought I had which was most similar is using a decentralized propagation mechanism, like DNS. Other schemes I've seen have tried to make sure that every participant agrees, or reaches consensus, on exactly which name is correct. Using something like IPFS to hold the entire global file of names.
However, propagation will make this protocol much simpler and it already works well enough for the real life internet.
Some key differences I had in my thoughts:
  1. Names can actually be nameSPACES anchored by a merkle root. When block space gets expensive again, your name can actually be part of a namespace managed by a third party. Each update issued by the namespace manager will include all additions/updates to previous names + new names, published with a link back to the previous update. This is effectively a side chain anchored to Bitcoin consensus.
  2. All names inside namespaces are actually signed in a multi-sig by both the namespace manager AND the owner/purchaser of the name. That adds censorship resistance. The namespace manager CANNOT seize your name because he doesn't have your private key. It's permanently embedded in the merkle root of his namespace chain on the Bitcoin blockchain. However, he might be able to keep you from updating in the future if you need to, which brings me to:
  3. The ability for a name owner to publish a unilateral transaction directly to the bitcoin blockchain in case he gets blocked by the namespace manager from updating his name. This can serve as a permanent redirect from the old name to a new name in a different namespace.
  4. Presenting a list of competing namespaces to the user is bad UX and has a centralization component to determine who is the most popular. Namespaces must be first come, first serve. The first one that claims a namespace owns it in the protocol. So what about Johnny-come-latelies? What if someone takes Google on the Bitcoin namespace protocol and they aren't google? Well, remember, this is rough consensus. Not everyone has to agree on the correct names! If someone takes google and Google comes on the scene and also registered Google on the blockchain, once people realize that real Google is on the scene, they just instruct their clients to permanently ignore the Fake Google and not propagate their names anymore.
  5. Point 4 also serves in the case of catastrophic namespace mismanagement. If Amazon screws up royally and loses their keys, they can create a new Amazon, and people will get the picture real quick. Again, rough consensus, not total consensus!
As you can see, this very similar to your idea, and I think it has lots of promise. I've been considering writing a client that can run alongside Core and watch blocks for names, and also create PSBT's to claim names when you publish them.
write
preview
3 sats \ 1 reply \ @kandycoder OP 30 Jan 2023
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.
reply
3 sats \ 0 replies \ @ursuscamp 30 Jan 2023
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