Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a decentralized name system on top of IRC

roberts.pm

Post reply on HN
Print view View original

11–20 of 65 posts

Re: Building a decentralized name system on top of IRC

#11

Post by aunderscored »

Uptrenda wrote: post #7
Retr0id wrote: post #3

I don't know how else to say it, this is a really bad idea. 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.

Spam is unwanted messages that displace what you want to see. In IRC: channels can be set to private which hide them from the channel listing. So that the server continues to operate in the same way. The software isn't doing anything outside of what is already allowed by these servers. Everything from the number of channels a user is allowed to create to limitations on expiry are already factored in to how people use…

This kind of thing falls under spam. IRC networks are not your infrastructure to use for any project.

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.

Re: Building a decentralized name system on top of IRC

#12

Post by charcircuit »

Uptrenda wrote: post #5
charcircuit wrote: post #2

There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. 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…

>There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. 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 a…

>why do you say that?

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.

Re: Building a decentralized name system on top of IRC

#14

Post by baobun »

Uptrenda wrote: post #5
charcircuit wrote: post #2

There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. 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…

>There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. 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 a…

OK, so, one thing isn't clear to me:

    1. Alice registers example.tld
    2. Bob registers example.tld
    3. Bob reveals example.tld
    4. Alice reveals example.tld
It seems there is now two rooms corresponding to the same name. Who controls example.tld? I'm missing uniqueness and it still seems vaguely racey.

Re: Building a decentralized name system on top of IRC

#15

Post by Retr0id »

dontdoxxme wrote: post #13

This is really abuse of public infrastructure if you really want to do this, look at veilid ( https://veilid.com/ ). Veilid provides modern crypto primitives to do this and more importantly the people running the network actually want you to use it like this.

pkarr is another project in this domain https://github.com/Nuhvi/pkarr

Re: Building a decentralized name system on top of IRC

#16

Post by Uptrenda »

baobun wrote: post #14
Uptrenda wrote: post #5

Earlier quoted context omitted.

>There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. 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 a…

OK, so, one thing isn't clear to me: 1. Alice registers example.tld 2. Bob registers example.tld 3. Bob reveals example.tld 4. Alice reveals example.tld It seems there is now two rooms corresponding to the same name. Who controls example.tld? I'm missing uniqueness and it still seems vaguely racey.

Both Alice and Bob check if a name is already registered beforehand. Lets say that both of them see that a name is available and go to register it at the same time. Either both will fail (due to taking X names each) or one will succeed (per the consensus requirements.) The software will indicate the results by checking the channel owner after registration for each server. So you know whether to try register a different name or not. So conflicts can still happen here but they're reduced by having unique TLDs + names, requiring small computations, and checking availability beforehand.

Re: Building a decentralized name system on top of IRC

#17

Post by Uptrenda »

charcircuit wrote: post #12
Uptrenda wrote: post #5

Earlier quoted context omitted.

>There is 0 security in this. It is also hard to understand because it uses random crypto that doesn't really accomplish anything. 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 a…

>why do you say that? 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 atomical…

The channel names are unique per server. Knowing the channel name isn't enough to infer what name it represents so you can't just go and register the name on other servers after observing channel names. The only way to know what a channel name represents is to do a lengthy computation for a possible name, tld, password (optional), and server. Depending on uniqueness -- this might not be practical.

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.

Re: Building a decentralized name system on top of IRC

#18

Post by heapwolf »

Uptrenda wrote: post #6
heapwolf wrote: post #4

if you're looking for an easier way to build p2p applications, you might be interested in the Socket runtime ( https://github.com/socketsupply/socket )

Looks like an interesting project. When I was building my library I considered UDP hole punching but decided to focus exclusively on TCP because of how bad UDP is to work with. The issue with UDP is you're going to have to write a poorman's TCP stack on top of it. 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…

actually using UDP is the whole point. we explain why it's superior to TCP in the guides (https://socketsupply.co/guides/#p2p-guide_how-p2p-works_why-...).

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.

Re: Building a decentralized name system on top of IRC

#19

Post by Uptrenda »

dontdoxxme wrote: post #13

This is really abuse of public infrastructure if you really want to do this, look at veilid ( https://veilid.com/ ). Veilid provides modern crypto primitives to do this and more importantly the people running the network actually want you to use it like this.

What part of Veilid provides a key-value store for DNS as a service? I'm not seeing anything on the site that mentions it.

Re: Building a decentralized name system on top of IRC

#20

Post by Uptrenda »

Retr0id wrote: post #15
dontdoxxme wrote: post #13

This is really abuse of public infrastructure if you really want to do this, look at veilid ( https://veilid.com/ ). Veilid provides modern crypto primitives to do this and more importantly the people running the network actually want you to use it like this.

pkarr is another project in this domain https://github.com/Nuhvi/pkarr

This is not human-readable and centralized. It can't be used as a name system
Post reply on HN