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

21–30 of 65 posts

Re: Building a decentralized name system on top of IRC

#21

Post by Uptrenda »

heapwolf wrote: post #18
Uptrenda wrote: post #6

Earlier quoted context omitted.

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…

No offense but your table is kind of deceptive. Obviously you can route between anyone if your strategy is to fallback to using a proxy server. Libp2p do the same thing specifically for the same reason [simplistic code.] But the whole point of p2p networking is to not require one. The reason delta enumeration is important is because the information can allow you to support more restrictive NATs without needing a proxy server. It's more work to write the NAT code and more testing but it is worth it.

Re: Building a decentralized name system on top of IRC

#22

Post by Retr0id »

Uptrenda wrote: post #20
Retr0id wrote: post #15

Earlier quoted context omitted.

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

ditto veilid, which is what I was responding to.

Re: Building a decentralized name system on top of IRC

#23

Post by Retr0id »

Uptrenda wrote: post #19
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.

veilid itself basically just provides a p2p backbone (where peers are identified by their public keys) on which you can build other applications. i.e. it's the replacement to the "random public IRC servers" part of this equation, and not the DNS-like system as a whole.

Re: Building a decentralized name system on top of IRC

#25

Post by heapwolf »

Uptrenda wrote: post #21
heapwolf wrote: post #18

Earlier quoted context omitted.

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…

No offense but your table is kind of deceptive. Obviously you can route between anyone if your strategy is to fallback to using a proxy server. Libp2p do the same thing specifically for the same reason [simplistic code.] But the whole point of p2p networking is to not require one. The reason delta enumeration is important is because the information can allow you to support more restrictive NATs without needing a prox…

nope. it's not a fallback server, if you read our docs you'd see it's using another actual peer, but also many of the other cases are not routable in other libraries such as libp2p (which does fall back to servers in most cases).

Re: Building a decentralized name system on top of IRC

#26

Post by charcircuit »

Uptrenda wrote: post #17
charcircuit wrote: post #12

Earlier quoted context omitted.

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

>The channel names are unique per server.

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.

Re: Building a decentralized name system on top of IRC

#27

Post by Uptrenda »

charcircuit wrote: post #26
Uptrenda wrote: post #17

Earlier quoted context omitted.

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…

>The channel names are unique per server. 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 the…

I'm not sure I understand what you mean. One channel is registered per server, for one name. Successful registrations require a super majority of those registrations to succeed. Lookups can be limited to a sub-set as long as the result number is at least greater than the minimum failure threshold for a successful registration.

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

Re: Building a decentralized name system on top of IRC

#28

Post by dangerface »

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…

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

Re: Building a decentralized name system on top of IRC

#30

Post by JanisErdmanis »

Retr0id wrote: post #23
Uptrenda wrote: post #19

Earlier quoted context omitted.

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.

veilid itself basically just provides a p2p backbone (where peers are identified by their public keys) on which you can build other applications. i.e. it's the replacement to the "random public IRC servers" part of this equation, and not the DNS-like system as a whole.

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?
Post reply on HN