I populate my nip05 from a static json file so have a look at https://gitworkshop.dev/.well_known/nostr.json but some sites have lots of users with nip05 so the response gets dynamically generated based on the name parameter I'm the URL.
Login to reply
Replies (4)
yes that's how i do it also, https://n.mleku.dev/.well-known/nostr.json
i should just point out that it's a hyphen not an underscore https://n.mleku.dev/.well_known/nostr.json => 404
this is my names object:
{"names":{"_":"4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f"}
there is no space in that for a path separator aside from the key string
if i am running a git-http service, i tried to do this, it's a serious PITA and the documentation is awful, but the point is related to how you translate that USERNAME for the web server, and how does the web server use that to differentiate same named repos from different users, it's just simplest, IMO to just make it a path prefix eg:
https://example.com/lez/somerepo
because nip-05 only gives you https://example.com there is no space in the json to specify any detail about anything other than the name match itself, and the pubkey
you could use the pubkey as a subpath also, you could put it in a header, this is http, maybe you guys are just not familiar with the retardation of http
I'm not sure I follow. The format is `nostr://<user-for-nip05>@<nip05-domain>/<repo-identifier>` the nip05 lookup gives you the pubkey and the relay hint
Take a look again and my nostr.json and you will see relays and also nip46 relays as per the nip05 spec.
yes, but that resolves only to an NPUB hex pubkey, not a URL
this is for a git-http service right? why leave this unclear, make an exact specification how the name goes into the path that is resolved, and it should be a path, not a subdomain, because not everyone has *cough* wildcard certs (and letsencrypt are bitches about ratelimiting)