Nip05 addresses enable a GET request to the server at the domain which returns user pubkey and relay information. In ngit we use that to find the repository announcement event and everything related from there.
Discussion
ohhh so you have
https://example.com/.well_known/nostr.json and you expect the http-git service to be at https://example.com right?
so with mine, that would be https://n.mleku.dev ?
yup, i get it
my nip-05 implementation on lerproxy (found in https://realy.lol in the cmd/lerproxy directory) only has a configuration to specify a local path where the nostr.json file is at, i would need to modify it so it additionally providesn actual network redirection address for anything other than `.well_known/nostr.json` it would be a small change
i was asking because i already have an easy to configure nip-05... it just only points to a file path... it is very simple to create an optional second clause, like, separated by a space or something on the line, i mean, really simple stuff
though, you also include the username there, this would imply a sub-path or some similar thing, i just use the default _ path for mine so it's just n.mleku.dev but i am thinking you mean to have distinct paths per user, so the user path needs to be part of the *actual* path of the redirection
just putting these thoughts all together, i would rather not tamper with nip-05 spec, but rather just define an appendix to it that says for your example, you should have this:
nostr.hu/lez/nostropus = nostr://lez@nostr.hu/nostropus as a standard remapping, so it simplifies how the web server routes the request
sorry to disrupt the joy there i just did literally implement a nip05 feature in my fork of leproxy (which automates getting certs, i recently added the ability to add your own paid certs) and i understood how it worked at the abstract level for the domain, and how all of those name@ parts refer to a different user but they don't refer to a different name or address so the web server would need some other scheme to specify
perhaps it can be simply done with an automatic http-basic path resolution rather than a subpath as i am suggesting, maybe this is just "implementation details" but i think it's important to establish a standard practise
I'm not sure if I understand correctly, but I suspect some misunderstanding here.
To be clear: the lez@nostr.hu here is the NIP-05 address itself. Not a HTTP authentication. It directs clients to relays + a npub.
what does the USERNAME translate into
let's say i am implementing said git-http service, how do i specify which path it looks for when it's lez vs DanConwayDev ?
No! NIP-05 allows you to specify a relay list for your name. It's a not so well-known feature, but part of the NIP-05 spec.
So when you do a `git clone`, it will fetch the gitrepo event 30617 (see NIP-34) from your NIP-05 relays.
All the metadata for the repo is stored inside the repo events. 1. the git server urls, 2. relays where patches are welcome 3. description and so on and on.
I'm not sure you quite understand it. There is no change to the nip05 spec. Git supports operating over other protocols and the chosen protocol is set in the remote URL using `protocol://` therefore we can't use the standard nostr andressing using `nostr:`. The anchor point of a #GitViaNostr repository is a `30617` git repo announcement event. This lists the chosen relays and git server(s) for the repo. We could just link to the event using bech32 naddr format but it's not human readable.
As we can't use standard `nostr:` addressing an opportunity was created to use a more human readable address point. So we did: https://github.com/nostr-protocol/nips/pull/1624
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?
also, you are right, i don't understand, the username part
i made a comment on the nip-34 issue to explain... it's just about "best practices" how to resolve the name so you can write a standard web service that has predictable behaviour
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.
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.