Thread

nice, so nip-05s are creating a redirection? or you have to host it on the same IP as the DNS name? what's the name resolution protocol exactly?

#golang has a "vanity import" scheme which is basically a meta tag that points to the "real" address, i have mine going to https://realy.lol but that points to https://github.com/mleku/realy and additionally i added a redirect header that bounces a normal access over to the actual hosting this thing `nostr://lez@nostr.hu` should equate to X.X.X.X IPv4 address at port 443 or port 80, so what is the protocol exactly?

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.

See https://nips.nostr.com/5

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

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 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.

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

The 30617 event contains the IP:port where git will connect.

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 https://example.com/ 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

that's not my question it's where does the username fit into the request that is forwarded to the http-git service

the domain is an address, yes, but the username is a qualifier that has to be separated you don't want to have issues with this: nostr://lez@example.com/somerepo conflicting with nosttr://dave@example.com/somerepo

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 ?

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

In your example, example.com is the NIP-05 provider, and not the git server, right? If you want to specify user for the git server, it is currently done in parameters: nostr://dave@example.com/somerepo?username=davesgitserveruser and this long username is used for the URL specified in the repo event as "clone" tag.

that is extremely verbose, why not design something simple like i suggested? you need to think about people implementing servers, it not just client side

The way it works: there is a URL nostr://lez@nostr.hu/identifier?username=gitusername 1. NIP05 resolved to npub + NIP05 relaylist 2. NIP05 relaylist is REQ'd for {authors: [npub], #d: [identifier], kinds: [30617]} 3. Repo is cloned from the 30617 event's clone tag, using 'gitusername' from original URL

also, think about it this way the nip-05 is only, and ONLY serving https://n.mleku.dev/.well-known/nostr.json every other route from that `/` can be anything you should recommend a scheme to resolve the name@ into an implied path in fact you can skip the stupid @ thing altogether and just make the name the first path element, it would be more easy to type and read

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.

aside from that, you can also use the nip-05 to decode a prefix, being the npub, which could be another option, but since you can't have more than one key in a json object with the exact same string, it's equally distinct as the hex pubkey, and human readable just trying to get you to think about how it's implemented so the spec is not complicated, do it this way, or be retarded. username@example.com has a standard implied meaning to put the username:password fields into headers in the actual request, the semantics are being muddled here that's what i'm trying to get you to consider, i think it's better to just do it as a subpath, but leave the actual URL how you are using it, web servers are webservers and maybe someone wants to implement this with some nginx configuration and your scheme doesn't make it clear where that username fits into it

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)

Still feeling misunderstood and hardly understand your desire. Do you want to serve your git under your nip5 host? You are the minority, but still you can do it. Add http://mleku@n.mleku.dev/gitroot/project as the `clone` tag. @ is part of NIP-05. If you skip it, people won't recognize that it's a NIP-05.

OK, I think I understand you now. So like nostr://nostr.hu/lez/nostropus better? I'm afraid NIP-05 has already broken the "standard implied meaning" of @ and nostr has embraced that. So nostr is retarded I guess.

no, i'm just saying i make a git redirection reverse proxy what path is lez@example.com/reponame resolving to because in case you didn't realise this is equivalent to an email or lightning address, which has a whole set of rules about resolution as well do i use the npub in the nip-05, do i use the name (which has to be unique by json syntax) and if so where do i place it in the path, it has to be in the path, or is it in the header be specific, it's not hard to decide on one scheme to use what's bugging me about this is that i deal with javascript structures on a pretty regular basis, designed by javascript programmers, and they have like 10 different ways of explicitly or implicitly designating types and so every single different piece of data their app produces needs to be processed differently please, just define a standard rewrite syntax, and then you know that nobody is going to screw it up you are working with two moving parts here, a router, and a server, and a server expects as stardard http(s)://example.com/path/to/repo.git as i said, i've tried to deploy git hosting and the Go tool i used was great but it had all kinds of other issues with it then i go over to the Git site and try to make sense of their instructions, *facepalm* http is really simple is it get, or put, is it in the header, or is it part of the path, is it a subdomain, is it an address, just decide on one, and make that the standard and nobody screws it up i can tell you haven't had much to do with web servers because they are the most arcane voodoo in computer science, only Go's implementation is really strict about the taxonomy of the parts i can make reverse proxies, protocol relays and all kinds of neat stuff, websockets, with go and http shit, but then i look at these other language implementations and it's a real hodge podge in comparison

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

1. View open PRs by looking at branches with `pr/` as a prefix. 2. Submit a PR by pushing a branch with `pr/` as a prefix. 3. Reduced trust in git server as state is always signed in a nostr event. 4. Maintainers can change git servers whenever they want and users will automatically pull from the new location.

no, it's not like that, lightning addresses also use this, it's borrowed from email and that was originally borrowed from ... i forget... maybe telnet protocol://username:password@address this is the basis of it, i think there is an RFC for it and all in http, this has generally equated to username:password being parsed into http headers in some way in the request, iirc for humans to read it, what you have proposed is fine, but for web servers you have to say where that username is going, and i say a path prefix is the simplest you presumably would do it with subdirectories right? this is the standard for http file servers, and git servers are literally this, each subdiretctory.git is literally a folder, and inside it is what in the "not bare" version on your system when you "git clone" if you add the extra part `--bare` to the git clone command it puts it in the format that the http git service is expecting, on the client side so you see what i'm saying, you have to define a route remapping, and for clarity of implementation, you should recommend a preferred method

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

The win is more obvious if you compare it to the old form "nostr://naddr[192 chars omitted]"

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.

It's confusing, noted. This argument about http headers does not stand if we are strict, because of the 'nostr://' scheme. I think it's also fair to assume that after the nostr:// we expect @ to mean nip05, not http username -- we don't even know if it's http under the hood. But still, it's confusing. The remapping is not algorithmic, but included in this event: https://njump.me/nevent1qqstda2vwm5ucl3qxa8rm0ah06npuanr6jr7mvhaqfqq8dsqp9543qgpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgq3qelta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq7vvqe5 In there, the "clone" URL actually holds https://github.com/lez/ as we are used to seeing. Maybe what's really confusing is the fact that it's not a real clone url, just a fancy pointer to it, I don't know. It has nothing to do with git clone urls we seen so far. My opinion is that nostr://nostr.hu/lez/nostropus would also be confusing. Because the git repo is not on nostr.hu server at all. And it's hard to tell people it's a NIP05, you just have to swap the elements and put @ in that. Maybe it's confusing because the host where the files are stored is not showing up in the remote url at all. It's equivalent with `nostr://npub1elta..../nostropus`. So it means "On nostr, find this user, and find his repo with this reponame" Am I right that you'd prefer "nostr://nostr.hu/lez/nostropus" instead of the current form?

What I didn't appriciate until the following docussions is that the use of a domain name in the URL heavily suggets that the git content is hosted at that domain. This is misleading and I'm not sure what to do about that. nostr:nevent1qqsqqqxkm0csfdqmpnswqj9hh2rxurdnajs5wx0fcd3ya37tr5ef2dcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqqqqsqdua4e nostr:nevent1qqs9ctx9cq2vxdsz856l62v5pptrls9xqtx9m9s4822g3u6n5sp7h8gppemhxue69uhkummn9ekx7mp0qgsyeqqz27jc32pgf8gynqtu90d2mxztykj94k0kmttxu37nk3lrktcrqsqqqqqp8hykqv https://github.com/nostr-protocol/nips/pull/1624#issuecomment-2557656165

Same here