Building a decentralized name system on top of IRC

I'm still waiting for the OAuth-based online US government ID for all citizens that lets us sign up for utilities, apply for colleges and loans, set up bank accounts, etc. instead of entering social security numbers everywhere.

When is that coming?

> 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 course it would be entirely possible to devise a system that treats them less as a commodity or enforces usage-based rights but to do so in a less rigid and mindless way than "no activity in N cycles equals forfeiture" (like Twitter and Google have done or announced their intent to do before) is hard and doesn't play well with pretending to be a neutral actor enabling a free marketplace of ideas.

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 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.

While technically true, your statements about Ethereum are misleading because as you know -- it is impractical for any random person to 'just generate Ethereum' with their computers and use it to pay for transactions. It's like you tried to make a technical argument but over-simplified it too much and left out key details for it to be meaningful.

>IRC is not distributed it's owned by a centralised provider who has complete control, >IRC has no consensus mechanisms a netsplit would make it trivial to create duplicate channels on the same IRC network.

This is true, but my design uses multiple servers. Netsplits only effect one IRC network. I am using multiple discrete networks. For the purposes of consensus it doesn't effect the software.

>You check channel availability then register, this by definition isn't atomic, it's a race condition between check and register. You need a way to wrap this in a transaction to prevent the race condition.

This is true but its also irrelevant. Either the register function manages to register enough names to meet the minimum threshold for success or it doesn't and the user can choose a different name. The design of the system minimizes such a scenario as unique TLDs, names, and passwords mitigate the potential for conflicts.

>Traditionally this is done with DNS but since you are trying to replace this requiring it is odd, how do you stop some one just hijacking your DNS once that problem is solved your scheme becomes pointless.

Every peer-to-peer application has the same issue including Bitcoin and Ethereum. It's not an issue with DNS. It's that there needs to be an initial way to know details about the network. This is called 'bootstrapping.' For now -- this is done by having a list of server IPs stored inside the software which is uploaded to a few places. Github and Pypi.

>it's centralised to 11 servers you can't trust.

This feel like you're just playing word games that mean nothing. Decentralization refers to network topologies and governmental designs wherein a single authority cannot control a system. Such a property is true about the system I've built by requiring a threshold of servers for agreement. A server doesn't individually have the power to control a name. So no it's not 'centralized.'

>I understand you check multiple channels/networks in an attempt to provide this protection but the underlying servers can do anything they want and there is nothing you can do about that

I think you've managed to miss the point of this design. It does provide a simple consensus mechanism across servers. It is mentioned in the fourth section titled 'How it should work.' I think most of your post is based on the misunderstanding that this system is simply load-balanced and doesn't include a consensus mechanism.

I know this is HN but not everything needs to be monetized. There is such a thing as doing something because you want to. People write open source software largely because they want to and if it helps them they might as well let others use it too. There's more than enough unused network resources on the Internet to make a free alternative to DNS. OpenNIC comes fairly close to this but still fails to provide a good registration system.

>enterprising businessman who grabs all of them

I'm mostly targeting short names that can be shared with people in place of IPs. So think about server lobbies where normally you might type in an IP to connect to a friends server. The current domain name system has popular TLDs but my design isn't based on fixed TLDs. The name can be anything and there's no 'most popular' TLD so name squatting isn't an issue.

It may be an issue if this were to emerge more for apps and websites though.

Hey people, I wanted to say thanks for all the comments: positive and negative. I've probably written hundreds of thousands of lines of code for projects over the years that had no interest at all. I am fairly good at engineering but very bad at choosing problems to work on. You have no idea how motivating it is for me to even have a single comment on anything I'm working on or thinking about.

No one I know is that technical and I'm not part of any communities that would get a project like this. Most of the time when I share something there are zero comments and it just ends up being invisible. So thanks. This will motivate me to keep working on my main project (p2pd) to make it stable and start writing program that I can run on a daily basis ('dog fooding.')