• git is already decentralized
• what NIP-34 actually defines
• we did this once already
• forty-nine stars
• the argument for building anyway
• what 526 downloads tell you

§git is already decentralized

“Git is already decentralized.” That is the most common response when someone brings up #nostr-based code collaboration. And it’s correct, technically. Every clone is a full copy of the repository. You can work offline, branch locally, push to any remote you want. Linus Torvalds designed it that way on purpose.

But open any real project and look at where the work happens. Issues live on GitHub. Pull requests live on GitHub. Code review, CI/CD, package registries, deployment automation. All GitHub. The git history on your machine is distributed. Everything around it sits on one company’s servers.

NIP-34 and a tool called ngit are trying to move that collaboration layer onto Nostr relays. The project has been in development since May 2023. It shipped pull request support in October 2025. As of this writing, it has 49 stars on GitHub and 526 total binary downloads across all versions.

That is not a typo.

§what NIP-34 actually defines

fiatjaf, the creator of the Nostr protocol, authored NIP-34 and it merged into the NIPs repository on March 5, 2024. Its status is “draft” and “optional,” which means the spec is stable enough to build on but not something clients are expected to implement.

The spec maps git collaboration onto Nostr events. A repository announcement is a Kind 30617 event containing the project name, description, clone URLs, maintainer list, and preferred relays. Patches use Kind 1617 and carry the full output of git format-patch in the event body, the actual diff lives inside a Nostr event, which still strikes me as a strange and clever choice. Pull requests are Kind 1618, pointing to a clone URL where the contributor’s branch lives. Issues are Kind 1621. Plain markdown, tagged to a repository.

Status tracking works differently from what you’d expect. Instead of modifying the original patch or issue, NIP-34 creates a separate event that references it. Kind 1630 means open. Kind 1631 means applied. Kind 1632 means closed. The original event stays immutable. Status changes are separate, signed assertions. It’s how Nostr handles everything, append-only events, never edits.

The tool that implements all of this is ngit, built by DanConwayDev in Rust. It ships two binaries: ngit for the CLI and git-remote-nostr for cloning via nostr:// URLs. I cloned a repo with it last week. The workflow is recognizable if you’ve used git before. ngit init announces a repo to relays. ngit send publishes patches. ngit list shows proposals. Version 2.0 added pull request support and a sync command for keeping local state in sync with relay events. The latest release, v2.2.3 from February 2026, added AI-friendly CLI flags --defaults and --force which says something about where the developer thinks collaboration is heading.

gitworkshop.dev is the web companion, also by DanConwayDev. A SvelteKit app that gives you a GitHub-like interface for browsing repos, reviewing patches, and managing issues over Nostr. Think of it as the read layer for what ngit writes.

§we did this once already

In 2005, Linus Torvalds created git because BitKeeper, the proprietary version control system used for Linux kernel development, revoked its free license. The Linux kernel depended on a tool controlled by a single company. When that company changed the terms, the project had to scramble. Torvalds wrote git in about two weeks. Decentralization was the explicit design goal.

Twenty years later, the collaboration layer re-centralized. One company. GitHub. 150 million users, 420 million repositories. Microsoft bought it in 2018 for $7.5 billion. The #git history on your machine is still distributed, but the issues, pull requests, CI pipelines, and wikis that make a project function all live on Microsoft’s servers.

We’ve seen what happens when that server decides to act like a gatekeeper. GitHub blocked developers in Iran, Syria, and Crimea from accessing their own repositories, compliance with US sanctions. In October 2020, the RIAA filed a DMCA takedown against youtube-dl. GitHub killed the repo immediately, then reversed course after the Electronic Frontier Foundation intervened. The point still landed. Your project exists at the discretion of the platform. The code is yours. The infrastructure around it is not.

I wrote about this same dynamic in my article on Nostr relays. Open protocols tend to re-centralize around whoever runs the best infrastructure. SMTP is federated. Gmail runs a third of all email. Nostr relays are dumb pipes. Five of them carry most of the traffic. Git is distributed. GitHub has the issues.

§forty-nine stars

So NIP-34 exists, ngit works, and gitworkshop.dev gives it a web UI. The question everyone asks: why is nobody using it?

Because the feature gap is enormous. GitHub is not just a git host. It’s CI/CD. It’s package management. It’s security scanning, dependency graphs, code search, project boards, and a social network for developers. Moving your workflow there means giving up all of that. ngit gives you patches, pull requests, and issues. No CI. No inline code review. No private repos, NIP-34 has no concept of access control, so everything is public.

The cold-start problem makes it worse. Code review requires reviewers. Issues require a community. You’re asking developers to move to a tool that nobody they work with has heard of, running on infrastructure that might drop their data. Nostr relays have retention policies. Some delete events after a set period. An issue or patch stored only on relays that shut down is gone. Git history survives because every clone is a backup. NIP-34 collaboration metadata doesn’t have that property unless someone is actively replicating events across relays.

This is not just a NIP-34 problem. Radicle has been trying to solve decentralized code collaboration with a different approach, a custom gossip protocol, CRDTs stored in git’s object database, and about $7 million in funding from the Radworks foundation. After years of development, it has around 2,000 repos on its network and roughly 200 weekly active nodes. Forgejo and ForgeFed are going a third direction, adding ActivityPub federation to traditional forge software. None of these projects have reached critical mass.

The pattern holds across all of them. Decentralized alternatives to centralized developer tools attract fewer than a thousand active users, regardless of the technical approach. The problem is the network effect, not the code.

§the argument for building anyway

Here is where I push back on my own pessimism, because NIP-34 has one structural advantage that Radicle and ForgeFed do not.

It runs on #nostr’s existing relay network. No new infrastructure to bootstrap. Any Nostr user can comment on an issue or review a patch without creating a new account, because their npub already works. A client that implements NIP-34 could show your code activity alongside your social feed. Zaps could fund bounties on issues. Your developer identity and your social identity would be the same cryptographic keypair.

That integration matters more than it sounds. One of GitHub’s quietly powerful features is that it’s a social network. You follow developers, star projects, see activity feeds. NIP-34 plugs into a social graph that already exists. The code layer just needs to connect to it.

fiatjaf’s own trajectory says something about how he sees this. He built gitstr as a standalone NIP-34 CLI, then deprecated it in favor of folding the functionality into nak, his general-purpose Nostr tool. Code collaboration is not a separate product in his view. It’s a feature of the protocol. Nostr is an event system. Patches are events.

But I’m not going to pretend that architectural elegance translates to adoption. Developers evaluate tools by whether they can ship code with them today, not by whether the protocol design is clean. And today, ngit cannot replace GitHub for any project that needs more than patches and issues.

§what 526 downloads tell you

The case for decentralized git has never been weaker on adoption and never been stronger on reasons. GitHub has more control over open-source #programming infrastructure than any single company should. Every developer knows this. Almost none of them are willing to accept worse tooling to fix it.

That is a rational response. You lose CI, code review, discoverability, and your entire professional network. You gain sovereignty over your collaboration metadata. For most developers, that trade does not make sense today.

ngit and NIP-34 might matter eventually, the way git itself mattered after BitKeeper pulled the rug. Or they might join the long list of technically sound tools that solved a real problem nobody was willing to pay the switching cost for. The 526 downloads suggest the market has not decided yet. More accurately, the market has not noticed yet.

#nostr #programming #decentralization #git