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.