Oddbean new post about login | logout nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqppemhxue69uhkummn9ekx7mp0qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qyghwumn8ghj7mn0wd68ytnhd9hx2tch2deau when I use uppercase in my nostr address, it says unverified. Is this case sensitive? It seems not because nostr:nprofile1qqs0cu4wf0x3g99dg0qz795j5taln5caux0929tkazem59pd9wqkm0spzpmhxue69uhkummnw3ezumt0d5hsz8thwden5te0dehhxarj9e3xjarrda5kuetj9eek7cmfv9kz7qgkwaehxw309ahx7um5wfjkc6t5v4ejummjvuhsk8lzt0 has an uppercase B set in her profile but lowercase in her nostr.json and it says verified...
It could be some redirection. Nip05 does not accept any redirections on the server side.
i'm pretty sure that in several places in the nips it is said that all hex and bech32 encodings are to be lower case only
it looks like the server is case sensitive in this case, it won't return output when queried for Chris: $ curl -v 'https://minestr.app/.well-known/nostr.json?name=Chris' < HTTP/2 404 $ curl -v 'https://minestr.app/.well-known/nostr.json?name=chris' < HTTP/2 200 { "names": { "chris": "..." } }
Thanks 👍 I was querying it using browser which I guess automatically changes it to lowercase before sending, which Amethyst mustn't. So why does it work for Bearetta@bitpunk.fm in Amethyst?
bitpunk.fm seems to have a different server setup that ignores the parameter part after nostr.json and always returns all the users eg https://bitpunk.fm/.well-known/nostr.json?name=bearetta https://bitpunk.fm/.well-known/nostr.json?name=Bearetta https://bitpunk.fm/.well-known/nostr.json all returns the same list i do the same for x0f.org actually--there's so few users that there's no reason to implement database lookup logic for bigger servers, or if they want to make it more difficult to enumerate users (for privacy), it makes sense to do so, and minestr.app apparently does
NIP-05 speaks about the user part being case-insensitive, but they don't mention if it should be the client (before sending) or server that lower-cases it (before querying), so i think amethyst is correct passing it as-is
Alright, thanks for the info. By the way, your LN address isn't working
It looks like it's something to do with what nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqppemhxue69uhkummn9ekx7mp0qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qyghwumn8ghj7mn0wd68ytnhd9hx2tch2deau said. At minestr.app I'm using path handlers to serve specific files for nostr.json queries. It works for lowercase for some reason, but for uppercase it bugs out. Whereas if I test not using a redirect (just a plain hosted file at alpha.minestr.app/.well-known/nostr.json, and then try to use Chris@alpha.minestr.app (despite the JSON name key being lowercase "chris"), it verifies as OK. This behaviour confuses me.
yeah i fully agree it's confusing ! i assumed Vitor meant a HTTP redirect (which never works with NIP-05) when he wrote that but you could be right i don't know which HTTP server you're using, so can't tell you exactly how to do it, but i think the right behavior to configure would be make it so that NAME argument from "https://minestr.app/.well-known/nostr.json?name=<NAME>" (or alternatively, the entire URL) is lower-cased before using it to find the specific per-user file (as the file system will be case sensitive). that would make https://minestr.app/.well-known/nostr.json?name=Chris return the same as https://minestr.app/.well-known/nostr.json?name=CHRIS and https://minestr.app/.well-known/nostr.json?name=chris, and make the verification work in all software. That the JSON name key in the returned document is lowercase "chris" is ok; NIP-05 is sufficiently clear that clients need to do that comparison case-insensitively, which is why Beareatta's works