I agree that you can have your IP addresses rug-pulled just like you can have your DNS rug-pulled. But using a keypair for a relay solves some other things. It allows a single relay to serve multiple endpoints (e.g IPv4, IPv6, Tor). It avoids the confusion of clients not knowing if a URL path is a new relay or the same relay. And it allows relays to switch endpoints in the event that DNS and IP addresses are both pulled, without all the clients not being able to know that it is the same relay. Also CAs won't need to be trusted anymore if we use that keypair for TLS. CAs are such a scam. I've done some development at

GitHub

GitHub - mikedilger/alt-tls: TLS provider for rustls supporting ed25519, plus tools

TLS provider for rustls supporting ed25519, plus tools - mikedilger/alt-tls

on this, but haven't gotten it working with secp256k1 keypairs yet (I think I can, but it would not be standards compliant and wouldn't interoperate with other SSL software) But this change is massively disruptive to how nostr currently works. Relay URLs are all over the place currently. Maybe there is a migration path, but it seems rugged with a lot of switchbacks, and you'll have to carry a water bottle to make it to the end.

"""If we are to spend efforts on this layer then I'd rather go for the entire IP thing and make it possible for networks to be assembled in decentralized and permissionless ways using local cables and wireless infrastructure, then merge together forming an ever-growing parallel internet, with decentralized routing that scales globally.""" YES YES YES YES YES

I'm down.

I agree that Nostr is very resilient against DNS attacks, but relying on DNS at all is still its biggest weakness. The DNS reliance issue isn't just about how well the network could hold up against a coordinated attack. Individual relay operators would hugely benefit from not relying on DNS while still having it as a nice option for easy discovery & user-friendly lookup. It's a lot harder for an individual relay operator to switch domains especially if they're repeatedly attacked at the DNS level each time they switch. But if they had their public key as a backup method for clients to connect to them with, clients could seamlessly stay connected to them after a DNS attack took place. There could even be a simple mechanism for DNS-based relays to announce their npubs which clients could automatically save in case connection at the DNS level failed at some point. There are also privacy issues & additional hurdles caused by making DNS mandatory for any sort of client-relay connection that will last through a dynamic IP change. I personally don't want to have to choose a domain registrar, choose a domain, purchase it, renew it, & deal with remote hosting of relay software. I also don't want before that to give my name, home address, & email address to a domain registrar & also ICANN if I'm not willing to pay extra to keep ICANN from having that info. Many more people would be running relays if all we had to do was download a relay app & run it on our laptop using a standard, home internet plan with a dynamic IP address. I should add that, based on other replies to my original message to you, I no longer think all content sent by relays not using DNS should be signed by the relay's nsec. But something like a TLS handshake when the WSS connection is 1st made should be performed so the relay can prove its identify. Regarding complete overhaul of the IP protocol, I agree that needs to happen. But I think it will be much more successful if done in more than 1 jump to a fully decentralized system without even having ISPs in the mix--especially because you'd be going against their financial incentives. As a step in the right direction which also keeps ISPs & their financial incentives intact, I propose what I'll call IPvPK (pub key) for lack of a better term. Instead of IPs being assigned at the ICANN or even ISP level, they could be user-generated pub keys. The user could send their self-generated pubkey to their ISP, & then the ISP could register it, share it with other ISPs, & hopefully provide a way for the user to update it as needed or wanted. Like with IPv4/6, any computer attempting to connect to another computer by IPvPK would be routed by 1 or more ISPs to it. Then something like a TLS handshake could take place where the connecting computer would send arbitrary data to be signed by the corresponding IPvPK's private key. With this system, we'd never run out of IPs like with IPv6, no central authorities (ICANN, ISPs, or CAs) would fully control who had what IP, & none of them could spoof packets meant to be from any given IP since each owner of each IP would prove their IPvPK identity with digital signatures. ISPs could continue offering IPv4/6 while any number of them at any adoption rate could start to support IPvPK. Not only could they keep their same financial incentives in place, but I imagine they would want to encourage their users to adopt iPvPK since it means less coordination for them with ICANN. Also, IPvPK connections would work between users of the same ISP even if that ISP was not connected to any other ISPs that supported IPvPK since no coordination with other ISPs or ICANN would be needed to ensure they didn't use IPvPK IPs used by others. That's because the odds of that happening would be similar to that of 2 people generating the same Bitcoin wallet address.