The biggest friction with #GitViaNostr onboarding is the git server setup. We have ideas to fix that with a nostr-permissioned git server implementation inspired by

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6's nostr:naddr1qqz8xmmwvupzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqvzqqqrhnyq32amnwvaz7tm8d96zuenfv96x5ctx9e3k7mg8rc3xy

We envision many public instances that allow user to push new repos with no signup and zero-configuraiton required.

Let me know if you would like this.

nostr:nevent1qvzqqqqqqypzpgqgmmc409hm4xsdd74sf68a2uyf9pwel4g9mfdg8l5244t6x4jdqythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qy88wumn8ghj7mn0wvhxcmmv9uqzqa9sg0pcwynwkc5tphyjvzfuqweahtuektzdchfeky8pe8xwgadd2ptew6

Reply to this note

Please Login to reply.

Discussion

Bad idea. You'll be debugging it for decades, and on boarding will be worse. Let git be git and let nostr be nostr. A better idea would be single-sign on via nostr to various git service. And one-click install options.

The idea is to use the git project's git server implementation with a nostr authentication layer. I think the is consiatant with the 'let git be git and nostr be nostr' philosophy.

The on-boarding should be better but you are right that I'll be be debugging it for decades.

Trying to build 2 nostr clients on different tech stacks simultaneously has meant I haven't been able to make the progress I would have liked quickly enough. Maybe maintaining a third would slow down progress too much.

nostr:nevent1qqs8ep486xycv9zlw28hwf0pq0vkehgsrdj50qjd2l0y63knr4vyh7sppemhxue69uhkummn9ekx7mp0qgsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqrqsqqqqqpmjawx3

A good way would have been to add #pubky which is git native identity and signatures, using ED25519 keys, tied to nostr identity. Another good system would be NIP-98 to log in to say gitea/gogs/gitlab. You also get free SSH, and commits, out of the box, for free. Key is to let each tool do its thing and expand the network effects. Then with a few tweaks you get enormous new functionalities. Git does come with a very basic server, yes, I've used it a few times, but it'll require a lot of support, and lacks alot of features. We were discussing this problem and using ngit for resilience with the Agentic folks today. I think in future there will be a an offering for humans (high support) and one for agents (low support).

When you mentioned pubky before as a native git identity before I looked into it but couldn't find any information about how to use it for git. Can you link to a getting started guide?

There's not much to it really. It's just an ed25519 key which has the same 64 byte hex string that nostr does for its privkey. So nostr already has an an ed25519 privkey which is native to git. It can do commits, ssh, clones, git identity etc. The #pubky is simply a base32 encoded public key in the profile (just like npub but better, without the unnecessary segwit checksum). So every nostr account gets both functionalities. Perfect for git.

I think what your saying is that it can already do some of what an ssh key can do with git because of its inherent properties.

I find it really difficult to understand the thinking here. Nostr privkeys are both nostr keys and git keys. But the argument I want to use them only as nostr keys, rather than use them both nostr keys and git keys, I cannot see as a technical argument. I just cant see it. It's like having the number "2" and saying, we can use that to add, but not to multiply. It's a thought process that I find alien, and see no way past it.

I'm not suggesting that support shouldnt be added to git for signing commits with nostr keys. It just seems there is a lower value proposition on focusing on that right now compared to the other #GitViaNostr tasks

There is no such thing as a "git key", there are only ssh keys you use to authenticate to a git server.

I'm guessing Melvin is using this term as pgp keya can do some actions as well as ssh keys eg, sign commits and tags.

The alternative git server implementations all have social collaboration layers (PRs, issues, comments, etc) built in which makes for a confusing UX for on boarding maintainers and for users stumble upon them via these git services repository pages.

And then you have to configure weird ssh stuff which is hard for the client and much harder for the server.

My biggest issue with Song currently is that I can't for the life of me get it to respond to the "smart" git protocol correctly.

If someone wants to fix that for me please do it!

Except for gitea, no other Golang implementation of a git server seems to be doing that, they all use the "dumb" protocol. And I can't understand the gitea codebase (haven't tried hard enough).

This is not even important, but since I failed at doing it I got tired and didn't finish implementing the proper NIP-34 features I wanted to, there is only currently a half-broken patch view UI that is not very helpful.

Oh also the server is lacking a proper view for standalone commits and standalone files.

We all get tired and are enthusiasm for things fluctuate :-)