Building a decentralized name system on top of IRC
roberts.pm
roberts.pm
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 are willing to pay for it, speculators will grab it and resell it for the "right" price. Free domains for everybody actually means free domains for an enterprising businessman who grabs all of them with a simple Python script in 24 hours, and then resells them for $10 a pop. We already see that with normal DNS, short and memorable domain names go for astronomical amounts, but because every registration costs money, registering more unusual domain names if you don't actually have a need for them is not a profitable strategy, and so good enough names can still be registered somewhat cheaply. You need to increase prices to make speculation unprofitable while still remaining affordable to end users. It's a balancing act.
If you don't create the barrier to entry yourself, the barrier to entry will be created for you, and not in a way you like or can control. Such a barrier doesn't have to be monetary, it can be (difficult) proof of work, centralized identity verification and abuse prevention policies, legal consequences for scalping, invitation / vouching requirements etc, but a barrier always exists, whether created by the system developers or the free market.
This only applies at large scales of course, if your system is used by 10 people and all of them trust each other, "grab any name you want for free" is totally fine.
When is that coming?
[x] Pretentious
How could someone as lowly as a mere programmer possibly understand the complexity of how things cost money and their impact on participation? Sounds to me like I should have sought your esteemed council before making this project to save myself the embarrassment. In future I will make sure to consult you before I do something.
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.
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.
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.
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.
As a brief example:
mycattest123.com: $17.75 plus $23.99/y
mycattest123.cat: $13.00 plus $49.99/y
>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.
It's not whether something should be monetized, but rather about whether it inevitably will. It's not a question of "if", but "by whom", "when" and "how much". Either you do the monetizing, via crypto or otherwise, or you hide your head in the sand, pretend that the issue doesn't exist and let the scalpers get all the profits.
It's spam. If you scale this up, the few IRC servers that currently accept this type of behaviour will start blocking it.
You might as well be trying to use blog comment sections as k/v stores.
If a channel typically attracts users and their discussion increases as more people join, which may happen over a very long time frame, then I argue that my design is actually less impactful than a traditional channel. Since it is not designed for discussion.
At the very least, I can tell you that Libera would define this as abuse and actively remove it. Our servers are for users to chat, not for software to communicate.
And to clarify on spam, this takes resources from the target of a given network. If that networks target is to be a platform for software communication, sure. But in general, IRC networks are there to relay chat, hence the Internet Relay Chat name. This kind of thing takes processing power away from users, and increases memory load on the server. Not to mention bloating it's services database.
There's also support for nodes that don't have public IPs at all, which connect to the network via some other node acting as a relay. In this case, they report the relay's node ID.
This isn’t derived from the stability of IRC itself but the network operators as there are many holes not accounted for.
You’re not guaranteed a channel on IRC networks. A network owner may decide to remove it or, if using Services, transfer ownership if someone requests. Same for nicks and other things.
I’d also be willing to bet the network operators did not sign up to host a database for free for some stranger online either.
You are using someone elses infrastructure, and even if you have done everything possible to minimize their overhead, you are still planning to use them for free. I think the other suggestions made here regarding options all have merits that I am not qualified to speak on; but I do know that decentralized/federated DNS is something highly sought after in bitcoin circles like on stackernews and nostr. You could use nostr very similarly to how you use it with your current implementation; I would very much love to use it to make remote access to services on my home network more accessible, and to allow others to use those services as well. There is a built in userbase of people that would like to host everything from cloud backups to online marketplaces to browser games, but using a centralized DNS is simply not an answer for them.
Seems like a pretty grave omissions for something that should be somewhat reliable.
Nothing stops someone from registering your domain. Nothing stops someone from doing a Sybil attack and just always returning an attacker's account public key.
The author would be benefit greatly by taking another look at blockchains for this problem. They typically are much better thought out distributed systems than what the author was able to come up with.
There is zero security if you dismiss every such measure to accomplish a level of security by saying that its just 'random crypto' that doesn't accomplish anything (why do you say that?)
>Nothing stops someone from registering your domain. Nothing stops someone from doing a Sybil attack and just always returning an attacker's account public key.
I think there may be some confusion in your understanding of the system. Registered names aren't visible, only their hashes. The design masks names through a verifiable delay function which forces registering parties to do lengthy computations to construct the lookup function. Since computations can be stored in bulk - names can be registered atomically across IRC servers without revealing what they are directly.
>Nothing stops someone from doing a Sybil attack and just always returning an attacker's account public key.
In the context of networking 'sybils' refer to being able to create multiple identities, machines, or so on controlled by the same person. But your usage of the term here is confusing because (1) users don't control third-party servers (2) users can't see names directly (3) there is a cost to creating names (4) and a threshold system is used to do consensus over name lookups and registrations (which was designed to solve the problem you're talking about.)
>The author would be benefit greatly by taking another look at blockchains for this problem. They typically are much better thought out distributed systems than what the author was able to come up with.
I would love to use a blockchain for this. There's only one problem. Currently there are no such blockchains that have zero transaction fees to use them. I think that such a system would be very useful. But it seems that no one wants to do it -- and working at blockchain startups for more than a decade has taught me that bolting forced monetization and funky tokens onto everything can make a system worse (or even unusable) for its intended purpose.
I think if you re-read the post you will see how I've addressed the problems you raised.
Because the information needed to lookup a name is equivalent to the information needed to register the name.
>Registered names aren't visible, only their hashes.
But domains are public information. Imagine if in normal DNS anyone could register google.com at any time. Claiming that its not insecure because people don't know google.com exists doesn't make sense.
>names can be registered atomically across IRC servers without revealing what they are directly.
But if someone learns the name they can register it themself. Two people can both claim to be google.com. If a new IRC server is added anyone can create a channel for an existing domain. If your answer to the problem of the same domain being registered by multiple people is that a domain should be both a name and an encrypted nonce you run into the problem where it might be more convienent to just pass over the public key.
>But your usage of the term here is confusing
That is my fault, I assumed this was a permissionless system where any IRC server was permitted to be used instead of a permissioned one.
>Currently there are no such blockchains that have zero transaction fees to use them.
Some cost near $0. A fork of one could be made to do so.
The idea of having masked names was only to prevent race conditions in the initial registration process. After the channel names are registered they are unavailable for other attackers to register and since a verifiable delay has to be done on the name to compute it -- there is adequate time to register the name across multiple servers.
A malicious server can reuse a channel name and have it hijacked by an operator. But the system also ties in ECDSA signatures with a basic threshold consensus algorithm across servers. So having a few servers (or even many) wouldn't allow a malicious third-party to compromise a name.
But there is not a limit for how many channels can exist for a single domain.
>After the channel names are registered they are unavailable for other attackers to register
Yes, but an attacker can use a different channel name for the same domain.
>So having a few servers (or even many) wouldn't allow a malicious third-party to compromise a name.
An attacker could associate their own key with that domain any number of times across any number of servers.
>Yes, but an attacker can use a different channel name for the same domain. >An attacker could associate their own key with that domain any number of times
How?
You literally just register the name again. In the rare chance you conflict just reroll the random nonce and try again.
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.
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.
1. Alice registers example.tld
2. Bob registers example.tld
3. Bob reveals example.tld
4. Alice reveals example.tld
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's owned by a centralised provider who has complete control, they can trivially take over any domain they want.
IRC has no consensus mechanisms a netsplit would make it trivial to create duplicate channels on the same IRC network.
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. IRC provides no way to do transactions. Even registering a channel on a network is not atomic because of the potential of netsplits, which is stated in the rfc.
How are networks choosen and distributed? You picked 11 random servers that meet your requirements. If I pick 11 random servers how are their ips shared? 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.
If you expect everyone to use the same 11 servers this isn't distributed, it's centralised to 11 servers you can't trust.
I think you are under the impression that IRC is distributed and so if you build a secure system on top of it, then the system as a whole will be secure and distributed. The problem is that IRC isn't secure or distributed it's centralised with no Byzantine fault tolerance.
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. Finally getting to the point of being on IRC and checking a channel has a lot of attack points none of which are accounted for.
The difficult part of any distributed bysentain tolerant system is the distributed bysentain problem IRC doesn't solve this problem and your scheme outsources it to IRC.
Charcircuit is just telling you the truth you don't want to accept.
It's HN, they don't understand how blinded they are by their bias against blockchain. I see these contradictions all the time and have learned it's pointless to reply.
>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 get why people are concerned about using other people's infra for this kind of thing. But I do see a use-case for that as a backup. I don't think I'd ever implement something like this without running my own server as the enforced source instance for my apps so long as my server was running. If every other IRC server wanted to prevent this kind of scheme from working on their machines, I certainly wouldn't hold it against them. But I imagine that if other people wanted to run a P2P app, they might have their own IRC instances and would be accommodating of my downtime, as I feel like I would be accommodating of theirs. Different strokes, and all, but I definitely see how this would be pretty analogous to regular IRC usage, as far as administration and data, so I don't have any particular grudge against it - at least not without looking at what kind of traffic tsunami it could eventually cause.
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.')
>Here sha3_256 is used again but this time inside hash160. The reason for this is stacking hash functions can help reduce the chances of finding collisions (you would need to find a collision in both functions.)
Don't you only need to find collision in the outer hash function?
The approach used by this library for NAT determination also seems to be an over-simplification of how NATs work in routers (which is the same problem that Libp2p has) and will result in having hole punching code that barely works. Some properties to consider:
- delta type -- this refers to how the NAT assigns external ports for mappings
- delta value -- this refers to any known patterns observed in the mapping
- nat type -- no NAT, UDP firewall, full cone nat, etc
There are special rules for how traversal can be accomplished depending on the variables above. It's quite complex. But supporting it all greatly increases the chance of punching success.
Another issue I see with this library (and this is personal preference) is the massive amounts of re-inventing the wheel (again -- Libp2p and Protocol Labs are notorious for this.) It seems like there are many custom protocols that you've built into your software but most of what you've built is already part of standard Internet protocols (e.g. STUN)
You can leverage a QUIC implementation nowadays for that - QUIC brings everything you need (session layer, congestion/flow control etc.).
and our NAT traversal success rate is comprehensive, every known routable path actually works (check this table https://socketsupply.co/blog/the-next-chapter-in-the-story-o...)
we're actually not reinventing too many wheels here, our work is conceptually based on DTNs — cited frequently in our guides and docs.