It is not enough to just make up a TLD, who is going to run that TLD? What happens when they censor you just like existing DNS can? How to stop spam and sybil?

All these questions are exactly what pkarr.nuh.dev was made to answer.

1. Bittorrent DHT is how you maintain ultimate censorship resistance

2. If you don't keep republishing your DNS-like record it gets dropped by the nature of the DHT, so that solves spam and Sybil

3. Your relay/hosting provider(s) who you already pay for keeping your data, periodically refresh your records on the DHT

Most importantly I tested all of that and showed that a small server can keep up to 100k users records alive on the DHT with >95% availability

Once you add aggressive caching, it is a solved problem.

But it will demand switching to ed25519 as the root identity

Reply to this note

Please Login to reply.

Discussion

> It is not enough to just make up a TLD,

I know that; but I could not not think of TLDs when you mentioned a DNS-like system, sorry. ^^;

> What happens when they censor you just like existing DNS can

Hm... First thought that comes to mind is how .i2p works; you "register" it by providing a key-based address and if your router doesnt respond within some time, it "expires". I could register ingwie.i2p today and should my router stop responding for some time, it's gone from the public list. (I actually intend to do that). Maybe a similiar approach where a DNS name is both a "nice name", but also part of the bigger resolution system? After all, "7xixuvjsnun5ladgpsl42mmetey3ysne22w4tlkj635xmh5w2xra.b32.i2p" is a DNS-name within i2p, whilst ingwie.i2p would be what a CNAME is in "normie DNS" - at least, when drastically simplified.

> How to stop spam and sybil?

That's a question relay authors and runners have been pondering on for a while now. strfry uses a "write policy" that one can implement as a sub-process, so I guess this is "a solution" but definitively not the be-all-end-all. Do you rely on community reports? How much credibility do you give them? Does it take N reports for actions to occur, and if so, how do you handle botted reports? Personally, I am leaning more towards a subscribe-model. As in, subscribe to curators who you believe can do a good job - and if they don't, switch. That, however, would bind more volunteer workers into the network and they'd want to be recompensated in one way or another. Difficult, in many aspects.

> 1. ... 2. ... 3. ...

Interesting. I honestly haven't looked in great detail at your solution to be honest. Though I should, it sounds interesting.

> But it will demand switching to ed25519 as the root identity

I am not a cryptography expert (like, at all... 100% noob, i just use what the respective software tells me to) but isn't this also the same algo used for tor addressing? I am very sure I've seen this algorythmn name before in conjunction with onion addresses - but, again, I am not perfectly sure.

When you mentioned DHT, I had to think of what IPFS does with it's DHT. How does your solution impact CPU usage? IPFS continiously works on the DHT and whilst the CPU usage isn't very big, it is noticeable, being neigh consistently at the top of my most resource heavy processes. (not by a lot though, to be fair.)

From client point of view it will either send a UDP message to the DHT and get a response, or send an HTTP request to a proxy server and get a response.

You will only make these requests as frequently as you make requests to DNS servers (infrequently), it doesn't do what IPFS do at all, just a censorship resistant distributed dns server.

My issue with foo.i2p is that unique readable names is untainable, people will squat and buy and sell and it is very hard to keep that decentralized.

Using ed25519 keys, makes it so the key itself is the TLD, you don't need http://.tld ... instead you can just do http://

Phone numbers are not human friendly but we already know how to do good contacts UX over that.