Replies (20)

Default avatar
nobody 1 year ago
It’s also funny how much time is spent on theoretical problems that nobody has.
It doesn't seem that complicated to achieve with IP addresses listed in a nip65-like event for relays and pubkey support in nip65 events. I doubt clients would see implementing it as a priority. It would be a fun project to make a PR for it in 20+ clients.
Not a lot for the relay part. But I started the no DNS pitch with static content (that shouldn't use http addresses as well) and the criticism for that was through the roof.
Ppl are going to hate this, but if you want a censorship resistant means of mapping ip’s to pubkeys or vanity names, I can tell think of a distributed ledger that can handle that…
There's no need to map ips to pubkeys, just pubkeys to ips. And pubkey to IP doesn't need a ledger. There is no need for a globally-synchronized naming structure.
But how do you solve the cold start issue? If all I have is a pubkey, how do I find the corresponding ip?
Certain DNS solutions, absolutely. Clourflare, AWS and one other one are bad news. Use AdGuard, Quad9 or NextDNS, and implement ECH. Simple as that.
Yeah, but chain operations become extremely expensive over time. > If all I have is a pubkey, how do I find the corresponding IP? There are many ways, but you basically would have a boostrap IP that can download NIP-65-like events of other relays. We could even use WoT to ask your friend's client to become the Bootstrap relay. Once you have a list of available options saved locally, you can easily get updated records by just querying a few of them. And if they go offline, you update the list with new ones. As long as you know the IP of a single relay, you can get all the others.