#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?
The 30617 event contains the IP:port where git will connect.
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
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
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
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
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, 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
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?
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.
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 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
