Figured it out. The spec requires HTTPs, and I was only serving up HTTP. Grabbed an SSL cert and enabled port 443 and it works fine.
Why would the spec require SSL encryption for essentially public information? Seems excessive...
Discussion
Yep. That's what I saw when I did a curl and was getting connection refused.
Well, SSL certs are free with Let's Encrypt. Everything should have an SSL cert today. It's assumed that everything does. Yes, it's public data, but all of Nostr runs on 443.
Sure, the web is assumed to be SSL wrapped these days, but little lightweight protocols like this absolutely don't need that overhead. I don't even have a website on that domain right now, I set up Apache entirely to service my NIP-05 identifier. I feel like NIP-05 should be able to work over either protocol... Consider the day when Nostr clients are doing hundreds if not thousands of these verification requests constantly. If it's on a domain with a legit website and other services, sure, go SSL. But if not, why add all the overhead?
To be even more lightweight, I could have written a little script that listens on port 80 and only spits out this one URL with the appropriate HTTP header for CORS. No webserver required, no encryption, super lightweight.
Agree.
It was proposed weeks ago to add DNS TXT record verification to NIP-05, so that NIP-05 could work with just a DNS query.
No webserver, no HTTPS, no certificate/CA, just a DNS query.
But it was rejected for the sake of simplicity.
Which is understandable too, by the way.
Honestly DNS makes way more sense to accomplish "domain verification" than going through a webserver....
Unless ws:// and tor