@sommerfeld may be interested dispute his current keyword mute list

Can't wait to play with it!

Appears you’re enjoying nostr

Thanks. I'm excited too.

@sommerfeld zapped ⚡️21,000 sats View quoted note →

👀 View quoted note →

where can I find the code for git-remote-nostr?

Its in the ngit repository:

GitWorkshop.dev

Decentralized github alternative over Nostr

found it

I'll give it a read asaic. interested in learning what you guys are doing.

Do I understand it correctly that when you "push" a pr branch, it publishes the changeset to relays as notes? So there is one maintainer who then updates the original/upstream repo with merged commits?

Interesting, but whenever I see cool applications built on top of Nostr I always end up asking myself: what's the incentive to maintain relays up and running (other than generosity ofc)?

You got it!

Good work buddy

Nice, I like the idea! I'm sure you already thought about how to handle forks, multiple maintainers, and more? For example, since Git is already content-addressed, I guess we could detect full repo forks by watching for the same hashes to be published to other Git servers/URLs which are initialized (published to nostr) by other npubs. And multiple maintainers wouldn't even need to be solved via Nostr, since their merge permissions can still be managed on Gitea, etc., right?

The repo announcement event can optionally list other maintainers. A fork, in the tradition sense, can be created by issuing a repo announcement using a different identifier. Alternatively, using the same identifier by an npub thats not listed as maintainer in the original; but it's polite to use a different identifier / name to avoid confusion.

For our side, the incentive is to make the other side (github) do the same For the other side (github), the incentive is the same incentive they've always had for offering "free" services: collecting whatever data there is to collect, gaining any influence there is to be gained

I released a remote helper as part of ngit v1.4. I'd be interested to here your thoughts. View quoted note → 1. it proxies to all urls listed in `git clone` so maintainers can switch between git servers (and potentially to other protocols like blossom) without creating friction for users who have already cloned. 2. it store the refs in a nostr event so the clone url doesn't need to be trusted to deliver the correct state. 3. it add open proposals to a `pr/*` branch namespace so they can easily be pushed and pulled without having to learn new commands and understand how patches work.