Here is a spec: https://github.com/nostr-protocol/nips/pull/1249
I have been cooking up a git remote-helper that would make working with nip34 feel more like using native git. cloning something like nostr://naddr123 would proxy requests to the git server(s) in the `clone` tag and if the `refs` tag exists, only fetch updates which match the repo event. For a maintainer `git push` would update the repo event and push to all git_servers listed in `clone`.
nostr:npub1elta7cneng3w8p9y4dw633qzdjr4kyvaparuyuttyrx6e8xp7xnq32cume has also been exploring the idea of doing away with the git server and using a git remote-helper that gets git data via blossom.
Hopefully the spec could meet all of these use cases.
Why not use (git+)nostr:(//)npub1xxxxxxx/some-project as git remote url? It tells more about the owner and the project, too. Relay discovery is a thing to solve but with purplepag.es we are quite good I think.
The git+nostr: scheme could be more descriptive to what kind of URL this is, e.g. where to paste it.
An naddr is the stardard way of sharing a parametrized replaceable event. The identifier isn't human readable which is unfortunate for our usage but never the less it is the standard.
There is nothing to highlight it is a git reference but this is the case for all the popular git remote helpers.
Its probably only going to be cut and pasted along with a command like `git clone nostr://naddr123` so maybe it doesn't need a git prefix?
The "npub/project" format is not a bad idea, I kinda like it. But we need to shove in relays somewhere in there?
I would push the relay(s) into the user field, and make it optional:
nostr://relay.one|relay.two@npub123/project
In most cases we can find the npub on purplepag.es or big relays. If somebody still wants better resilience, he can add as many relays as he wants.
With the remote helper included in ngit I ended up supporting:
nostr://npub123/identifier
nostr://npub123/identifier?relayhint=relay.one&
nostr://naddr123
Its probably best for a stricter schema for relay hints which could be generalised for unencoded references to replacable events. Do you have any suggestions?
naddr please, because my repos are all on git.fiatjaf.com which is not in my outbox list.
I'm not sure what you mean? naddr and npub/identifer?relayhint=relay.one both contain the same data. one is encoded and the other isn't. I found the human readability of the unencoded version to be useful to make sure I'm pushing to the correct repo.
Oh, I didn't know there was a ?relay thing at the end because Coracle didn't display the URL and instead tried to render a preview.
nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn
basically you can add a query parameter with 'relay' in the name and it will decode the value. this way multiple relays can be specified. to prevent ugly encoding of characters like :// affecting the readability it will assume the wss protocol unless ws is specified.
this seems all seems a bit loose to me and may lead to clients producing urls that look different.
I personally like your way more (because of readability) and that's what I was thinking Nostr URIs would look like in general before bech32 encoding was introduced, but I still think it's better if we have a single canonical way of encoding things and naddr has more momentum (it's also easier to copy-paste if that matters). What do you think?
is it a problem if you can use either?
I've released there is a problem with the format. if you dont specify a directory name, git will use anything after the last `/`. so in this case it will add the ?relayhint=git.fiatjaf.com to the director name.
perhaps we should switch to the less intuative but still readable:
nostr:://npub123/git.fiatjaf.com/relay.damus.io/identifier
Would be neater. Would you still accept URIs without the relay?
yes, it might be able to find the event but its better to include a relay hint.
intuitive?
Yes, spelling error. But the new proposed format is shorter. I'm concerned about implementing loads of ways of doing it and forcing anyone else who wants to use the cloning syntax to do the same.
I have enhanced this suggestion here with the need to specify the protocol git should use to fetch / push to the git server as maintainers may want to push over ssh but fetch over https.
You are right, we don't need the git+ prefix. Nobody uses it anyway.
