Replying to Avatar Sjors Provoost

Handle different push and fetch remotes

My repo can be fetched from `https://git.sprovoost.nl/instablossom.git/` by anyone. To push I use a git:// remote which goes over SSH.

But in order to use git-remote-nostr I had to replace both remotes with:

```

origin nostr://npub1s6z7hmmx2vud66f3utxd70qem8cwtggx0jgc7gh8pqwz2k8cltuqrdwk4c/instablossom

```

This causes a problem, because git push will now update the repo on Nostr but then it fails trying to push to the https origin. I can work around this by adding a second origin and manually pushing there.

I ideally I should be able to configure the push origin that git-remote-nostr uses under the hood. That URL should not be published (it's unreachable).

Avatar
DanConwayDev 1y ago

I thought a `git://` URL uses the native git transport which is unauthenticated and unencrypted, whereas `ssh://` or `git@example.com:user/repo` formats use ssh?

I noticed the problem of a lot of nostr repos advertising their git servers with ssh 'clone' urls and git-remote-nostr failing to clone as fetches via ssh require authentication.

Of course, fetched should be auth for a private repo and some git servers dont even offer https. So the helper can't force all fetches through https. Also some like to auth over https so all pushes can't be via ssh.

The solution I implemented in v1.4.5 for https/ssh was to try over the protocol specified in the repo event and if it failed, try again with over the other protocol.

So if you change the clone URL in your repo event with `ngit init` to ssh/https, your pushes should succeed. Its ineligant though because it willl, in either the pull or fetch scenario, try over an undesirable protocol first.

I could add a protocol parameter to the URL so the user could specify the desired protocol and use a different one for fetch and push?

The tools should also nudge maintainers to use the desires fetch URL in the repo announcement event.

Reply to this note

Please Login to reply.

Discussion

Avatar
DanConwayDev 1y ago

Here is a suggestion for updating the nostr:// git standard based on needs emerging from usage:

nostr://ssh/npub123/relay.damus.io/my-repo

nostr://npub123/my-repo?relayhint=relay.damus.io&server-protocol=ssh

nostr://naddr123*

*no support for specifying server protocol

note that `git clone nostr://...` will name the directory with anything after the final `/` unless a directory name is specified.

I personally think the first format has the best balance of conciseness and readability. To articulate it more precisely, rather than by example, it is:

`nostr://///`

I'd love some feedback before implementing. nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub16r0tl8a39hhcrapa03559xahsjqj4s0y6t2n5gpdk64v06jtgekqdkz5pl nostr:npub16r0tl8a39hhcrapa03559xahsjqj4s0y6t2n5gpdk64v06jtgekqdkz5pl nostr:npub1uplxcy63up7gx7cladkrvfqh834n7ylyp46l3e8t660l7peec8rsd2sfek nostr:npub1s3ht77dq4zqnya8vjun5jp3p44pr794ru36d0ltxu65chljw8xjqd975wz

Avatar
MichaelJ 1y ago

Having a means of specifying the git connection protocol looks good to me. Two things:

1. I personally prefer using a query string for relay hints and server protocol. It keeps the repo address itself concise and a little more human-friendly, while extra detail can be added as needed in the query.

2. In addition to npubs, will we be able to use NIP-05 addresses? Npubs are rather cumbersome. Ideally, I'd want to be able to type out a repo address into my command line, rather than always having to copy-paste it.

Avatar
DanConwayDev 1y ago

the query string doesn't work for macos users unless they put it in quote so I don't think we should be advocating this anymore. see nostr:nevent1qvzqqqqqqypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy2hwumn8ghj7ur4wfcxcetjv4kxz7fwvdhk6qpq7rxwfs2c9pzp2dukptp4ysxdwajpw0n6ejd0kjjxg87vkc9w3e9qf9ynpq

NIP-05 addresses are interesting. I always have to go to a profile to see what a users nip05 address is so I might as well copy the npub. On the other hand, its nice to be able to tell from the remote url who the user is and I can't recognise may users npubs. They are also more concise. Does anyone have an opinion on that?

Avatar
DanConwayDev 1y ago

I've implemented this with `?protocol=&user=` or `nostr://fred@ssh/npub...` to enable overrides for push.

I've also updated `ngit init` to default to using https clone urls, as this is the most sensible for fetch.

Given that most repo events include ssh clone urls, I'm tempted to just always use https for fetch and ssh for push (with a https fallback) unless the `protocol` override is used. push failures of ssh are instant whereas over https sometimes needs to be prompted for credentials.

Next up I need to actually implement the override.