Nostr

This is now implemented in https://git.fiatjaf.com/song and its companion pre-push hook:

nostr:nevent1qqs90ehppsjqsqzlw0x6lp7uhdfv7ym8fuug3und83sv4py8jrdasmcpzpmhxue69uhkztnwdaejumr0dshszrnhwden5te0dehhxtnvdakz7qgcwaehxw309ahx7um5wghxvmt59emkj73wvf5h5tcn8e7qw

Hopefully it will work with ngit soon, but it works without ngit now using just the pre-push hook:

mkdir flower

cd flower

git init

git remote add origin http://yoursongrelayandserver.com/flower

ln -s (which song-pre-push) .git/hooks/pre-push

git config song.signer ''

echo 'peony' > name

git add .

git commit -m 'add name'

git push origin master -u

And the pre-push hook will sign a kind:30618 and push it to the server. The server will check that it comes from you and store it if it does, and will create a repository on its side upon receiving the event (named "flower"). Then the git push will proceed and since the kind:30618 has the correct branch name and the commit id in it, it will be authorized.

The next time you have a commit you can just git push and it should work normally.

Later you can publish a kind:30617 with more metadata if you want, and if that includes a "maintainers" tag then those maintainers can also create branches and push to your 'flower' repo.

I guess I should write this in the song README file.

nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p nostr:npub1uplxcy63up7gx7cladkrvfqh834n7ylyp46l3e8t660l7peec8rsd2sfek nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1useke4f9maul5nf67dj0m9sq6jcsmnjzzk4ycvldwl4qss35fvgqjdk5ks you might be interested or have criticisms.

nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr please let me know if I got this right.

Brandon Tompkins 1y ago

I asked Grok2(beta)fun AI to help me understand this post, This is what it said:

The message you're referring to outlines a new implementation for managing Git repositories over Nostr, a decentralized network. Here's a breakdown with a dash of humor:

- **Context**: Someone named Dan is excited about a new feature or workflow that's been implemented in a project called "song" on a Git repository. This isn't your average Git setup; it's like if Git and a social network had a baby on the blockchain.

- **The Flow**:

- **Whitelist of Creators**: Only certain Nostr public keys (npubs) can create repositories. It's like an exclusive club where your cryptographic key is your ID.

- **Local Git Setup**: You start by initializing a Git repo locally, which is as standard as making tea in Britain.

- **Git Announcement**: You use a command with some special flags to announce your repository on Nostr. This is akin to sending out an interstellar signal saying, "Hey, I've got a new repo here!"

- **Remote Setup**: You add a remote origin but with a Nostr twist, using a URI scheme that probably looks alien to traditional Git users.

- **The Pre-push Hook**: Here's where things get interesting. Before you push, there's a hook that signs your push with a Nostr event (kind:30618). Think of this as your repo's secret handshake to prove it's really you.

- **Server Interaction**: The server, upon receiving this signed event, checks if it's from an authorized user (you), and if so, creates the repository on its end. It's like the server says, "Ah, I see you're Dan, the repo master. Let's make this happen."

- **Subsequent Pushes**: After this setup, your regular `git push` should work smoothly, as now the server recognizes your commits like an old friend.

- **Future Enhancements**: There's mention of publishing more metadata later (kind:30617), which could allow others to manage or contribute to your repository, expanding the club's membership.

- **Community Engagement**: Dan tags some folks, perhaps looking for feedback or just to share the joy of this new Git-Nostr hybrid workflow. It's like shouting into the digital void, hoping for echoes of interest or constructive criticism.

In essence, this system integrates Git's version control with Nostr's decentralized identity and event system, creating a workflow that's both secure (thanks to cryptographic signing) and decentralized (no central authority needed). It's Git, but not as we know it, Jim.

Reply to this note

Please Login to reply.

Discussion

No replies yet.