The ICANN Domain Problem, Solved With Nostr? \ stacker news ~nostr

The ICANN Domain Problem, Solved With Nostr?

710 sats \ 14 comments \ @freakoverse 23 Jan 2023 nostr freebie

Looking forward to decentralized domains whoever figures that out, however, I have an idea but it has a problem:

I'm not sure if this is possible, but here goes. What about putting a name, and then from that name a public and private key pair is generated, inputting that public key in a (Nostr-based or supported via extension) that name would make the browser read the associated public key for it, and loading in the data that it has from relays.

Example: -I generated a public/private key pair using the word whatever.com (or just whatever) -I type that word, whatever, in the browser, which would then load in the data from its associated public key.

The issue, as you've realized, is that the private key would be known to everyone as they generate the same key pair from the name.

If this issue is solved, meaning there'd be a way to make the private key.. well.. private, then that's that, I think, we've achieved decentralized domains! =3

Thinking it through while considering different solutions that others have made, here's a potential solution:

Nosweb

A file that takes care of registering and connecting a Nostros public address with a human-readable name.

Aside from not allowing a user to take/register a name by connecting it to the address that they control with one that someone else already took/registered, this file would only hold the data that connects an address with a name and nothing else. Saving on storage.

Clients (web browsers) that are built on top of Nosweb, or current ones that implement it, would have users type the name in the URL field, and the browser would look through the Nosweb file for said name and its connected public address, and find the site files (HTML, CSS, etc) to load it in.

This Nosweb file would be held by relays that choose to host it, and gets updated with every new name that's registered. First come first served.

The site files would be hosted on a relay, and the user that controls a name/address sets that info and can change it.

The name can also be given/connected to a different public key as well, where that new info gets update on the Nosweb file as well.

I'd also imagine that if this gets developed and is out in the wild, there'd be different Nosweb files with different IDs (Nosweb#204, Nosweb#201, etc) where some relays might want to control what names with their addresses they want to respect/host, as a result, clients (web browsers) would have a section in their settings page where the user would control which relay, or rather, Nosweb file to prioritize first over the other, to resolve conflict of names/domains.

With that same, keep in mind that a ".com" or ".whatever" is not needed when registering a name with an address.

In terms of sharing an address from one person to another, there'd be two ways of doing so, considering the different Nosweb files out there:

-Check out my website: whatever -Check out my website: whatever@nosweb403

In the first example, the user would just enter "whatever" and see the website load in, and the browser would showcase in the URL field next to that name what Nosweb file this is from.

In the second example, it's more secure for both parties to know this, the send is assured that they received would enter that name-address and see what's intended, and the receiver is assured that they exactly received the correct address with no worry.

The only issue left now is the spam-registration problem.

Other than that, I think this is a good idea to solve the domain ICANN issue.

view all related items

1133 sats \ 5 replies \ @lightcoin 23 Jan 2023

A file that takes care of registering and connecting a Nostros public address with a human-readable name... This Nosweb file would be held by relays that choose to host it, and gets updated with every new name that's registered. First come first served.

There are a couple of critical problems here:

there needs to be a way for relays (or whoever wants to reference the file) to come to consensus on what the current state of "the file" is
there needs to be a way to prevent someone from registering and squatting on every possible name

ICANN solves these problems in a relatively centralized way by controlling the allocation of TLDs and domains.

Namecoin was the first protocol to solve the problem in a decentralized way, and since then many other re-implementations or extensions of this solution have been created (ref: https://lightco.in/2017/11/06/bns-2017/).

These days, I think "solving the naming problem" using a global naming system is probably an antipattern, and public keys + petnames is the better solution. See this thread by Zooko of "Zooko's triangle" fame, which has helped nudge me further in this direction: https://twitter.com/zooko/status/1434220535240482819

11 sats \ 2 replies \ @ursuscamp 23 Jan 2023

The problem with public keys is that it moves the centralization out toward discoverability rather than the actual name store. This is why something like a global source of truth like the bitcoin blockchain actually offers some technical advantages here.

Ultimately a Bitcoin L2 protocol that hashes current namespace to a Merkle tree on the Bitcoin blockchain would certainly work nicely. The question then becomes, how does this protocol work? Can we make it work without a federation?

Imagine a network that uses proof of work to find solutions for global names. These miners (or name finders) could just spend their time searching for solutions for names. When they find a solution for a name, they publish it to the Bitcoin blockchain. They could do this on demand, or use free time to search for solutions to common names/words.

Of course, this ties the economics to Bitcoin. Finding a name must be at least as expensive as publishing a transaction, but the benefit to the miner would actually need to be more than the benefits of mining Bitcoin with the same time.

The difficulty for finding a name solution could be tied to the current Bitcoin difficulty, but also to the entropy of a chosen name (using some common algorithm). Less entropy -> higher difficulty

There's a lot to think on there, and I am just spitballing, of course.

3 sats \ 1 reply \ @lightcoin 23 Jan 2023

a few links to check out about this:

0 sats \ 0 replies \ @ursuscamp 23 Jan 2023

Thanks. I will check these out

0 sats \ 1 reply \ @kandycoder 29 Jan 2023

I've been toying with an idea that changes the paradigm with respect to the two critical problems mentioned above: Just allow multiple registrations of the same name, and let the user disambiguate, and allow the user to "pin" the one that is relevant.

Squatting would probably be solved, because common names that are over-registered would intrinsically lose value.
Scamming might be solved, if people could distinguish by popularity rating.
Relay records could be kept truthful by requiring updates to be signed by the owner as determined by the Bitcoin blockchain.
This solves the problem of lost keys, because a new registration could simply replace an old one, and eventually the old one would become stale and drop out of relevance. (Of course such things as the popularity rating would restart, but that's probably a good punishment for losing one's keys.)

0 sats \ 0 replies \ @lightcoin 30 Jan 2023

what is the benefit of "registering" a name then? why not simply have users share their keys wherever they would have shared their name, and have the name embedded in the key? e.g. if I go to your profile here on stackernews and see you've shared your nostr key, then when I import it into my nostr client you could be added to my address book as "kandycoder".

10 sats \ 1 reply \ @Eximpius 23 Jan 2023

What about a master private key/public key that has subkeys for accessing the address. Then those subkeys only give access to the domain to view the site?

0 sats \ 0 replies \ @Eximpius 23 Jan 2023

That way anyone can have the key pair to access the site but not have control over the domain name.

148 sats \ 0 replies \ @l0k18 23 Jan 2023

Can Nostr prevent my kids from being abducted by human traffickers too? How about resurrection and eternal life?

It's not hard to tell that someone (A bearded, septum pierced chap, at minimum) is paying people to shill for what seems to be becoming his chosen "web5" implementation.

I'm gonna say this again and again every time I get the pique to make a post, that:

Nostr is not a complete distributed system design because it has no consensus, in a similar way to how IPFS lacks consensus and has wound up being mostly hitched to the Ethereum/Cosmos/Avalanche/Solana/Polkadot ecosystem and the NFT pump and dump racket.

In order to achieve this qualification there needs to be a set of countermeasures devised against sybil attacks and incentives for relays to operate that pay the server rental and internet connection costs, and to cache and deliver network data to clients.

Nostr will become a lot more relevant when at minimum you can pay rando relays to keep your profile data online, and users can reliably connect to each other without the delays and lag of the initial propagation of new data, or the update of data.

I'm not saying it has to be LN, though this is the logical choice for incentivising Nostr relay operators. When it comes down to it, wishes and dreams are not currency, for they are far too numerous to have scarcity value.

I'm sure I'll get an unpleasant response to this post, as I have in several previous times trying to point this out, but maybe you people will start to talk about things that distinguish your excitement from marketing campaigns.

1 sat \ 0 replies \ @siggy47 23 Jan 2023

This would be fantastic if it works. It would fundamentally change the internet.

1 sat \ 0 replies \ @freakoverse OP 23 Jan 2023

Here's a pic: https://proxy.irismessengers.wtf/insecure/plain/https://nostr.build/i/nostr.build_7353.jpg