I wonder why they did not build on Nostr keys and events. Anyway, the pubkey-dns resolver is super cool! It should be complemented with a browser extension for looking up public keys in your social graph.
They looked at it, of course. John had a pretty convincing set of reasons. Ed25519 is far more widely deployed than taproot keypair. And you need that interface with bittorrent mainline. It's faster, works on low power devices, deterministic. Schnorr nonces can be lattice attacked too, potentially. Good news is that you can have both. Sign a pubky field in your profile. Then put your nostr pubkey in your DNS record and you have a two way link. Think of it like NIP-05 for bittorrent mainline (20mm nodes). This would give nostr clients that use this the full power of taproot and the full power of ed25519 (pubkey, git, tor, ssh, matrix, signal etc.). It's way better. https://github.com/melvincarvalho/noskey https://image.nostr.build/c2ca7ae71b18b1c271a7dedd77d0f1fbc7a5120bd3594d182f9e76fb4f667763.jpg
Using Secp wasn't an option. For censorship resistance, size really matters, and Mainline DHT is orders of magnitude bigger than the next bigger overlay network and I don't think humanity will ever bootstrap a DHT in the millions of nodes ever again. Mainline (as almost every other overlay network) uses Ed25519 exclusively for mutable items. As for Nostr events, I assume you mean as the format for the data, and here again we went with DNS packets, since you will be hard pressed to come up with something more appropriate for the use case and the encoding is brilliant, definitely better than JSON :)
Have a look at this link https://ianix.com/pub/ed25519-deployment.html