Nice work. I really like the idea of song - lightweight git server without PRs and Issues to support nip34 repos. The matching aesthetic of a minimalist UI is great.

Using nostr events as authorisation for updates is really good. AUTH events aren't shared beyond the user and relay. This doesn't allow other contributors to confirm the new commits came from that npub. What if the repo event included a references to the latest branch tip and this was used as aruhoriastion instead?

That way git pull could also validate the commit was approved by the npub.

Reply to this note

Please Login to reply.

Discussion

I'm not using AUTH, it's a normal ephemeral event sent over HTTP that the git-server immediately discards, but I like your idea more. We need a spec for that.

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.

I like the remote helper for naddr1 codes, but can you replace the :// with : for consistency? Or maybe just do the naked naddr1 directly.

The git-remote-helper that takes stuff from Blossom could work (I don't think it is worth doing, but that's another matter), but it is somewhat out of the scope of NIP-34: it's just a new way of hosting git repos. We could add it there too if it turns out to be good.

I think git helpers require URL format, like ://

True, that settles it then.

if all commits are like notes ( content/hash ), is possible to expose a git repository as nip34 nostr notes, with some kind of reverse proxy ?

I think we would have problems when committing large files in nostr events. Probably there are relays that limit the size of events. And this is the kind of error that doesn't surface for weeks when a project is started.

it can work for read only project.

yes. the first ngit prototype recreated the entiregiit repo with a nostr event per commit. it ran into these limits.

Yes, git forces you to specify as either nostr://naddr123 or the even more ugly nostr::naddr123

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.

nostr:nevent1qvzqqqqqqypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqy2hwumn8ghj7ur4wfcxcetjv4kxz7fwvdhk6qpqr4mf3d5sx6t7ql8c4gmsjyssvmn4aj8cha5ule3mlg8sjp2fgs9srg2mz9

You are right, we don't need the git+ prefix. Nobody uses it anyway.

FYI, https://gitworkshop.dev/repo/nips . Some devs moved from github or don't have accounts.

sounds like a feature for "ngit node start" and blossom webtorretent, tokio style. :) . maybe an commit/patch can be expose like this and can be download ( lfs ) from multiple sources.