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.
ok, but how does the "username" go into the req, it's a field in the header, or is it part of the resolved path, or...
everything else is fine, just where does the username come into it
the https://example.com/.well_known/nostr.json is the URL
if we trim off that path to the json file we get
but you want to use the username, so how do we specify that in the HTTP request, is it a header field, or is it an implicit path, or what?
Discussion
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://
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)
The purpose of the nostr git URL is to locate the nostr repository. The git server(s) can chop and change overtime and can always be discovered via the nostr repository announcement event.
The nip05 address format is totally optional. You can use nostr://npub/relay-hint/identifier if you like.
i can't believe you don't get it
the URL format is fine, good
but the semantics of user@example.com is entirely dependent on the protocol, and it's two pieces, the router, and the server
how does the username relate to the nip-05 json and the - optionally - npub (the name is unique anyway) just define a mapping, and nobody screws it up
if you are gonna leave that thing open you are inviting trouble
but idk what to say
i ported a C implementation of the hamming code and i had a lot of trouble imputing the ACTUAL type that was being used by the compiler so that my code produced the same result, in Go, you don't implicit type casting, it has to be explicit
this is exactly the same kind of mental model issue you are demonstrating, typical C programmer, you have some mapping in your mind, but you won't say it
if you don't, have fun supporting irritated devs using more strict typed languages, you thought this evening was fun, hahaha i'm done, gonna sign off on this
don't just submit to the stupidity of arbitrary nonsense
recommend... in RFCs they use the SHOULD verb a lot for this case, meaning this is preferred because it maes implementation more clear and differences in implementation should be avoided if possible, because they lead to remapping errors, so define a standard mapping, and you will have no problems with people who want to use apache vs nginx or their own homespun golang or C http server
the git-http protocol is simply a http file protocol, it uses paths, natively
it's just a variant of what is done with SSH
the reason why i'm needling about the remapping is because i know this, and i know how http lets you remap to whatever, but leaving out stipulations in specifications leads to interop problems and you simply don't want that, idk how this is hard for you to understand
implicit things are fine in idiom so long as you can easily find them explicated
too often, they are not, and you have to dig around, read thousands of words that are not telling you the important point until you get to some fucking footnote that finally makes it clear
just please don't do that, make it simple, it's simple, why complicate it?
the @ syntax is good for people
but it's weird for http servers
I totally misunderstood the premise of this conversation. I think what you are saying is that nip05 is poorly consteucted and your making a mistake by using it. I though you need help understanding nip05 and how it fits into the nostr git URL scheme update. That supirsed me given the knowledge you have displayed elsewhere on nostr. Sorry for the confusion there.
Take a look again and my nostr.json and you will see relays and also nip46 relays as per the nip05 spec.