I'm cooking something for nostr:nprofile1qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyzsq3hh327t0h2dq6matqn5064cgj2zanl2stkj6s0lg4t2h5dty6vuxagm

Hey git loversdev, does this make any sense to you?

#nostrdesign #dev

Reply to this note

Please Login to reply.

Discussion

"loversdev", nice unintentional copy/paste typo haha

I liked this so much I have already implemented some of it.

Just need a `search` and clone command in ngit.

I'm thinking if the clone command make really sense. We can force it via the search workflow, so the user can double check the repo trustworthiness (via the mantainer npub + WoT indicator).

This should avoid easy fraud attempts using well known names.

I like it. We could even force it via `git clone nostr://amethyst` with a git remote-helper.

But this also exposes to scams.

Adding a NIP-05 to the mix could solve the problem, but a good format is not easy to spot:

nostr://_@vitorpamplona.com@amethyst

?? haha

I would use ngit to search the repos, and let git the usual clone command (or invoke it from the search)

Either `git clone nostr://naddr123...` which clones. Or `git clone nostr://amehtyst` which searches and clones the selected repo.

But nostr://amehtyst cannot be unambiguous, so it is open to scams.

The naddr1 is fine.

nostr://amethyst would search for events that have amethyst as an identifier and present the options to the user to decide which one, if any to choose (using description, WoT, etc).

Ok, so it would works like I imagined the search command.

Would rather have search, with results ordered by my WoT.

how about ngit clone naddrs ? this will add an .git folder with just config set to git remote, and use later git pull/fetch/....

I see 2 flows:

1. start with git, and later add ngit / nostr collaboration (init/clone) .

2. start with ngit collaboration (init/clone) and later add git/scm.

In 5-10 years, an AI will read comments / issues / proposals and generate the app and upload to git repo, so, the idea of ngit working independent in the beginning will make sense in the future .

PS: SCM is more than git, ( #fossilscm , #jj, #pijul, #radiclescm, ... )

Ah, I noticed the nifty little flowchart at the top, when I logged in today. Like!

In nostr:npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk's previous iteration the order was 1) nostr, 2) ngit, 3) any git server, 4) gitworkshop.dev.

I liked that (and implemented). 1) nostr - the communication protocol, 2) ngit - git tool to interact with nostr, 3) any git sever, as thats still required but just to access the authoritative code, 4) gitworkshop.dev

> as thats still required but just to access the authoritative code

This make sense! Actually it is an optional part.

I will revert the design to the first iteration.

How does it integrate with “any git server”? Are the git commits stored there and only PRs and issues are stored in Nostr? Maybe you could make that more clear in the graphic.

Exactly, it's like the git over email workflow, only patches move via nostr, while a public git server store the full codebase.

Probably we need to ad a diagram that explains that, near the maintainer-contributor section.

Thanks for the feedback!