Live data from Hacker News

Building a decentralized name system on top of IRC

roberts.pm

51–60 of 65 posts

Re: Building a decentralized name system on top of IRC

#51
post #44

> DNS costs money to use (which I argue is not suitable for all uses.) This kind of thinking is a trap that I see many people fall into. Domains cost money because they have to cost money. Human-friendly names are a scarce resource (there can only be one google.com and one @johnsmith). They have value, and the market tends to reach equilibrium. If a scarce resource costs (or is given away for) less than some people a…

> Domains cost money because they have to cost money. That's not entirely true. They cost money because they're market commodities and thus have market value. Making them cost non-trivial amounts of money to register is a way to de-incentivize scalping by reducing the profit margin but it's mostly done because it enables registries to pocket the premium that would otherwise go the the scalpers (aka "squatters"). Of c…

One big problem I see with this, is it sounds like you're proposing we dramatically expand the scope of registrar duties while also proposing we stop paying them.

Where are they going to get the money to fund their nuanced and mindful enforcement of usage based rights? Is a team of legal specialists going to review domain applications for less than $15/y?

It sounds like your concern is that private companies are making a lot of rent off public goods. I could have an incorrect understanding of this, but isn't it all run by ICANN at the end of the day? A solution might be to make sure the rent captured on domains goes back into funding public goods. Like a digital land value tax.

Re: Building a decentralized name system on top of IRC

#52
post #51
post #44

Earlier quoted context omitted.

> Domains cost money because they have to cost money. That's not entirely true. They cost money because they're market commodities and thus have market value. Making them cost non-trivial amounts of money to register is a way to de-incentivize scalping by reducing the profit margin but it's mostly done because it enables registries to pocket the premium that would otherwise go the the scalpers (aka "squatters"). Of c…

One big problem I see with this, is it sounds like you're proposing we dramatically expand the scope of registrar duties while also proposing we stop paying them. Where are they going to get the money to fund their nuanced and mindful enforcement of usage based rights? Is a team of legal specialists going to review domain applications for less than $15/y? It sounds like your concern is that private companies are maki…

I'm not talking about changing anything. I'm saying the registrar system is set up this way. It's never easy to completely rearchitect a system once it is already in place and well-established. I'm simply arguing that the way it works isn't a law of nature but a consequence of the underlying ideology and economic system.

Re: Building a decentralized name system on top of IRC

#53
post #52
post #51

Earlier quoted context omitted.

One big problem I see with this, is it sounds like you're proposing we dramatically expand the scope of registrar duties while also proposing we stop paying them. Where are they going to get the money to fund their nuanced and mindful enforcement of usage based rights? Is a team of legal specialists going to review domain applications for less than $15/y? It sounds like your concern is that private companies are maki…

I'm not talking about changing anything. I'm saying the registrar system is set up this way. It's never easy to completely rearchitect a system once it is already in place and well-established. I'm simply arguing that the way it works isn't a law of nature but a consequence of the underlying ideology and economic system.

The glaring hole in the alternative you proposed has nothing to do with the existing system being well established.

Re: Building a decentralized name system on top of IRC

#54
post #33

Earlier quoted context omitted.

What are assumptions involved for submitting and retrieving node’s IP address with a given public key to a Veilid network? For instance how does new users discover other Veilid nodes. Are those baked in statically? What happens if public IP addresses of the network change?

There's a list of public bootstrap nodes, similar to how Tor bootstraps. Nodes report their own IPs as part of a signed (and timestamped) record, which can change over time. Once you've found one node, you can query it for information about its peers. Because connection information ("dialinfo") is signed, it can be re-shared with other peers. There's also support for nodes that don't have public IPs at all, which con…

Very cool. It would be interesting to see applications built on top of Veilid in the future.

Re: Building a decentralized name system on top of IRC

#55
post #53
post #52

Earlier quoted context omitted.

I'm not talking about changing anything. I'm saying the registrar system is set up this way. It's never easy to completely rearchitect a system once it is already in place and well-established. I'm simply arguing that the way it works isn't a law of nature but a consequence of the underlying ideology and economic system.

The glaring hole in the alternative you proposed has nothing to do with the existing system being well established.

Sorry, I must have missed the part where you pointed out a glaring hole because all I read was an explanation of how it's hard to change things after the fact (which I agree with) and some gesturing at human nature (which is contextual, i.e. it's human nature to act a certain way within a given environment but that doesn't mean it's not also human nature to act differently within a different environment).

As others have pointed out, domain names didn't start out as a highly valued commodity. Arguably they only became that during the dot-com boom when domains functioned as brands. I'd even go as far as saying they largely lost most of their value from that time period in the Web 2.0 days when startups started slapping random syllables together and dropping letters and have instead become more of a speculative asset, especially with the flood of new TLDs nobody can keep up with.

In fact, there are market restrictions enforced by various registrars like requiring legal presence in a given country for ccTLDs or providing content in Catalano and/or information about Catalonian culture for dot-cat domains. Of course there are workarounds for most of these but as I said these are just bandaids bolted on after the fact, just like premium pricing tiers.

Re: Building a decentralized name system on top of IRC

#56
post #55
post #53

Earlier quoted context omitted.

The glaring hole in the alternative you proposed has nothing to do with the existing system being well established.

Sorry, I must have missed the part where you pointed out a glaring hole because all I read was an explanation of how it's hard to change things after the fact (which I agree with) and some gesturing at human nature (which is contextual, i.e. it's human nature to act a certain way within a given environment but that doesn't mean it's not also human nature to act differently within a different environment). As others h…

If we're going to discuss this, I'd like to keep things on point. My specific question was, how do you propose paying for this system of allocation when the entire premise is to eliminate non-trivial domain fees.

As a brief example:

mycattest123.com: $17.75 plus $23.99/y

mycattest123.cat: $13.00 plus $49.99/y

Re: Building a decentralized name system on top of IRC

#57

Earlier quoted context omitted.

>How? You literally just register the name again. In the rare chance you conflict just reroll the random nonce and try again.

The nonce isnt random. It's deterministic.

The time lock is pointless then. This is what I meant by random crypto making it hard to understand.

This blog post would be simpler to understand if you started out without any crypto. If I were to write it I would start with the case of a single IRC server. Then explain a channel is a key and the topic is the value. The first person to register a key on a server can control the value. Then to expand this approach to multiple severs you introduce the idea of using a kdf of the key concatenated with the irc server's identity.

Re: Building a decentralized name system on top of IRC

#58

Earlier quoted context omitted.

The nonce isnt random. It's deterministic.

The time lock is pointless then. This is what I meant by random crypto making it hard to understand. This blog post would be simpler to understand if you started out without any crypto. If I were to write it I would start with the case of a single IRC server. Then explain a channel is a key and the topic is the value. The first person to register a key on a server can control the value. Then to expand this approach t…

The time-lock acts as a way to ensure names aren't revealed the moment channels are registered which would create a race condition where attackers could hijack names by registering them on other servers.

The channel name is something like time_lock(name_meta_data, server_details) -> deterministic channel name based on the parameters passed to the function (output is unique per server.) Just like if you used a hash function you get the same output for the same input. Since the time lock needs a certain amount of compute to elapse (and a certain amount of time to do it) -- it allows time for the name owner to register the appropriate channels on other servers.

Re: Building a decentralized name system on top of IRC

#59

Earlier quoted context omitted.

You claim here that there is a cost to creating the domain but rule out Ens because it has a cost? You can't make both claims. You can generate Ethereum and buy domains with it much in the same way you do here. You rule out DNS as it doesn't have a standard registration but IRC doesn't have a standard way to register channels nickserv isn't on all IRC and they have different implementations. IRC is not distributed it…

I see what you're saying but your whole argument seems extremely black and white. It's like: you're saying that because there's a theoretical scenario where every server can over-take a name then the system as a whole isn't valid which just isn't true. A consensus system doesn't need to provide every property of a blockchain for it to be valid. Just good enough security for the problems that it solves. >You claim her…

Since you don't use IRC for anything more than an unreliable and easily spoofable key value store, why bother with implementing an IRC client? You could easily write a client server on UDP 58 client sends the key and server replies the value. Create a list of 13 IP we just trust and run your dnssec on top of that? Ez

Re: Building a decentralized name system on top of IRC

#60

> DNS costs money to use (which I argue is not suitable for all uses.) This kind of thinking is a trap that I see many people fall into. Domains cost money because they have to cost money. Human-friendly names are a scarce resource (there can only be one google.com and one @johnsmith). They have value, and the market tends to reach equilibrium. If a scarce resource costs (or is given away for) less than some people a…

In the early days of the Internet, domains were free. They also took weeks to register.

Which just proves my point. The barrier to entry doesn't have to be monetary, a competent human being individually checking each application works just as well.

There's also the point about scale, if your network is small and you trust your users, which was the case on the old internet, you can get away with a system that assumes no speculators.

Post reply on HN