NIP-34: Git Remote Nostr URL format and helper spec #1624
Conversation
add Git Remote Nostr URL format so clients can provide appropriate clone urls. This is used by ngit and gitworkshop.dev minus the usage of nip05 addresses. See this discussion of the format: https://njump.me/nevent1qvzqqqqqqypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy88wumn8ghj7mn0wvhxcmmv9uqsuamnwvaz7tmwdaejumr0dshsqg993aqt7e4v2p3cu06axwzsz999s798d04u27e50nn52la7t6t5dy94kk26 add wider git remote helper spec implemented by git plugin bundled with 'ngit'
|
|
||
| - `nostr://` - git syntax for a protocol URL | ||
| - `<user>@` - optional ssh user for interacting with Clone URLs | ||
| - `<protocol>/` - optional prefered protocol for interacting with Clone URLs. eg. ssh or https |
There was a problem hiding this comment.
I think this needs some further explanation, what is an example scenario, why the protocol in the clone URL is not enough.
There was a problem hiding this comment.
it enables maintainers to push to git servers using specific ssh keys or over authenticated http. It came out of discussion on this ngit issue.
ngit has since been updated to largely ignore the protocol listed in the clone tag and instead silently try protocols until it succeeds and record when a non-default one works best.
This nostr url remains the only way however to specify a non-default ssh user key.
How much context do you think I need to include in the nip?
There was a problem hiding this comment.
now I realize it's totally offtopic to the PR. Lets discuss in chat group. I have additional questions, but dont want to block this.
|
|
||
| If a `30618` cannot be found or git config item `nostr.nostate` is `true`, use state from the first Clone URL. | ||
|
|
||
| ### 3. Use `pr/*` branch namespace for 'Open' patches |
There was a problem hiding this comment.
I would mention how to browse the draft PRs.
There was a problem hiding this comment.
this remote helper spec doesn't support it. The guidance here is to use other tools eg ngit. I'm not sure the mention of a specific client like ngit is appropriate for inclusion in a NIP.
| Struture: | ||
|
|
||
| - `nostr://` - git syntax for a protocol URL | ||
| - `<user>@` - optional ssh user for interacting with Clone URLs |
There was a problem hiding this comment.
I guess overriding ssh user is not possible if using NIP-05 in the url.
There was a problem hiding this comment.
It can possibly be the NIP-05 user, too
that is covered in line 202 and 203.
| \*relay hints SHOULD be [URL encoded](https://www.w3.org/Addressing/URL/4_Recommentations.html) eg `ws%3A%2F%2Funencrypted.com` and may omit `wss://` for brevity and readability. | ||
|
|
||
| for example `nostr://[email protected]/ngit` or `nostr://npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr/relay.damus.io/ngit` | ||
|
|
There was a problem hiding this comment.
I think it should be mandatory to use nip05 relays if somebody wants to use their nip05 in a git remote url. It should throw error if either:
- there are no nip05 relays and no relay hint in the url
- the repo event is not found on any of the nip05 or hint relays
But I have no strong opinions on this. It's possible to use the bootstrap/fallback relays to find the repo (30617) event.
Anyway it should be clear that the NIP-05 relays or the hint relays are used to find the repo event, which contains the repo relays. All subsequent operations go to the repo relays.
There was a problem hiding this comment.
good clients that show the nostr git url should include a relay hint inline if the announcement event isn't on, at least one of, the nip05 relays. this should be a client implementation detail.
|
Thinking about this it sounds like "decentralized DNS", i.e. we use public keys to point to internet addresses. Maybe it should be more generalized instead of just a Git thing? |
In this PR we are just using Are you wanting to reserve the |
|
my issue with this is i don't understand where the userrname fits into the http request is it an implicit subpath, eg goes to or do we put "name" into the http header like is used in HTTP-Basic-Authentication like this: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization i might be quibbling over "implementation details" in that you could do it either way, but it's usually better to stipulate "The Right Way TM" for this kind of thing so implementations don't make incorrect assumptions that lead to later mysterious interop problems. |
| @@ -96,6 +94,9 @@ The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply` | |||
| ["parent-commit", "<parent-commit-id>"], | |||
| ["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit | |||
| ["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"], | |||
|
|
|||
| ["branch-name", "<custom-branch-name>"], // optional short name for use by git-remote-nostr | |||
There was a problem hiding this comment.
Is this just an implementation detail of git-remote-nostr? If yes then maybe we shouldn't include it here.
No, that wasn't my point, but now that you're saying it then maybe we should! Like someone is probably already playing with the idea of publishing a standalone event kind:10053 that contains some DNS-style records and then using those to resolve But that doesn't matter either, we could have both as this is so more specific. |
|
Regardless of that, I think the proposal here is too intertwined with ngit and so far to me contains a lot of big features that are definitely interesting and worth exploring, but mostly superfluous to me. So we should leave this PR open here for a while without merging to see what else is going to happen before we settle on it at the risk of bloating NIP-34 in unwanted ways. |
on the inclusion of nip05From the discussion on nostr, it seems that @mleku and @fiatjaf both had the intuition that the data resides at the domain included in the URI rather than being distributed. I suggest that we wait for a bit more feedback on nip05 in in response to @mleku
The purpose was to reference a npub in a human readable way, reusing an existing design pattern (nip05). Your suggestion is much less ugly from a URI stand point but no longer uses the nip05 format. If its not intuitive that its using the nip05 then the intuition is that the data is stored on the domain. I'm not sure nip05 addresses play a prominent enough role within nostr for it to be immediately identifiable as nip05. on what to do with this PR
On the wider git remote helper spec: I agree, it add complexity and whilst some people have seen it as a huge UX improvement, it hasn't has much usage so this thesis is not well enough validated. This is why I said:
|
|
using human readable name resolution implies DNS, unfortunately i think what's missing from your scheme is the replication... i think if you move away from referring to the NIP-05 identity and switch over to using the NIP-01 https://github.com/nostr-protocol/nips/blob/master/24.md#kind-0 this might be relevant but it is problematic in the way that the user can change it. most people don't, and probably devs are the least likely to want to if they are using it as a label tied to their nostr-hosted repos. however, there can be name conflicts because of the lack of a consensus about these names, and yes this is part of the reason why nip-05 was devised so, i think, unfortunately, you really have to do which is a bit annoying because i know for my stuff this means in my import blocks they are now minimum 64 characters long before they specify path elements. something to consider is that in most cases, toolchains have ways to make this easier, like in Go i can make up some bullshit, like "git.mleku" as my domain and use a replace directive to point that at the nasty long i don't have a clue what would be required to make this as low friction as possible but i'm happy with this work-around for my own stuff i appreciate what you are aiming towards, it just needs to be as simple and intuitive as possible, and using nip-05 is distasteful to us dEcEnTrAlIzEd maniacs... so yeah, npub should be the nostr "domain name". |
Add Git Remote Nostr URL format which can be used as a normal git clone address when ngit is installed. This used by ngit and gitworkshop.dev, minus the usage of nip05 addresses which @lez is working on adding. It is also partially supported experimental WOP tools like @lez's git-remote blossom and @Guga implementation of git-remote-nostr. We are now collaboration together. See this public discussion of the format on nostr.
Add wider git remote helper spec implemented by the git plugin bundled with 'ngit'. This is probably less useful for inclusion in the NIP but I'm not sure where else to put it. Should it be omitted?