NIP-34: git stuff
Git already is distributed; the collaboration layer is the weak point
Git does not need Nostr to be distributed. The repository format already moves well. The weak point is the social and coordination layer around Git: where a repository is announced, who maintains it, where issues live, how patches are sent, how pull requests are discussed and how a developer discovers the current state without trusting one company-owned forge.
NIP-34 answers that by using Nostr events as the public collaboration rail around Git. A repository announcement says, in signed form, that a pubkey maintains or mirrors a project. Other events describe repository state, patches, pull requests, pull-request updates, issues, status changes and replies. Git continues to move code. Nostr carries the coordination and identity around it.
That distinction matters. NIP-34 is not a replacement for the Git object database. It is closer to an open forge protocol. A project can still be cloned from ordinary Git servers, but the collaboration signals can travel across relays and clients. The promise is not that every developer will abandon GitHub tomorrow. The promise is that the project graph does not have to be owned by one website.
Announcements, clone URLs, patches, PRs, issues and status
The central object is a repository announcement, kind 30617. It uses a d tag as the repository identifier, then optional tags for name, description, web URLs, clone URLs, relays, maintainers, labels and the earliest unique commit. The personal-fork tag is important because it lets a user publish a fork without falsely claiming maintainership of the base project.
The source also defines a nostr:// clone URL format. With a suitable Git remote helper, a developer can point git clone at a Nostr address such as an naddr or a pubkey/NIP-05 plus repository identifier. That is where NIP-34 becomes more than a social card. It starts to connect the developer command line to relay-discovered repository metadata.
The collaboration objects are more ambitious. Patches use kind 1617 and can carry git format-patch output. Pull requests use kind 1618, with clone URLs and commit tips that needs to be pushed before the signed event is published. Issues use kind 1621. Status events use kinds 1630 through 1633 for open, merged or resolved, closed and draft. Review events then let comments point at specific file paths and line ranges.
This is a lot of surface area, and that is the honest reading. NIP-34 is one of the richer NIPs because code collaboration is not just one event kind. It has identity, repository discovery, Git transport, issue discussion, patch identity, branch state, review context and status changes.
A young NIP shaped by actual forge work
NIP-34 entered the visible file history in March 2024 and has stayed active. DanConwayDev is prominent in the recent history, which matches the public ngit and GitWorkshop work around NIP-34. The change log is useful because it shows a standard being sharpened by implementation rather than only by abstract protocol preference.
In 2025, NIP-34 gained PR and PR update events and saw fixes around patch revision status and NIP-10 tagging. In April 2026, PR #2312 added the nostr:// clone URL specification. Two later April 2026 changes removed an unused refs tag extension and corrected an overclaim about NIP-09 and state reset. Those edits are small on paper and large in product meaning: they decide what a real client can rely on.
This history is also why NIP-34 is not a finished replacement for GitHub. It is better read as an active forge protocol: enough to build serious experiments, still young enough that implementers need to follow the repository history.
ngit, GitWorkshop and command-line clients make the idea concrete
The most useful implementation trail starts with GitWorkshop and ngit. GitWorkshop describes itself as a web client for NIP-34 Git collaboration over Nostr, covering issues, pull requests, code review and Git exploration. DanConwayDev's ngit-grasp page presents a GRASP server with NIP-34 Git events, relay metadata and Nostr authorization. Those pages show the standard as a working forge direction, not just a markdown proposal.
The command-line layer is important too. n34 describes itself as an open-source CLI for sending and receiving Git issues, patches and comments over Nostr. A NIP-34 ecosystem needs both: a web surface for review and discovery, and command-line tooling that respects how developers actually work.
The practical test is boring and strict. Announce a repository, clone it through the advertised path, submit a small patch, push the referenced commit, publish a pull request, update the PR and then open the same thread in another client. If any step needs a private API or hidden service state, the NIP-34 story is not yet complete.
The risk is building a forge-shaped maze
NIP-34's strength is also its risk: it tries to model a whole collaboration system. That is necessary for serious Git work, but it means clients can implement only part of the NIP and still advertise support. A repository card without review tooling is not the same thing as a forge. A patch event without a reliable clone path is not enough for maintainers.
There is also a trust boundary around maintainership. A signed event can say a pubkey announces a repository. It does not magically prove the person is the rightful maintainer of a project known elsewhere. Clients need to show maintainers, earliest unique commits, fork markers and clone sources clearly, especially when projects have many mirrors.
Read NIP-34 in the wild
NIP-34 is where Nostr meets git. Repositories, patches, issues and maintainership can be represented as signed events, making open-source work visible beyond GitHub-style platforms.
The promise is not replacing mature developer tooling overnight. The promise is portability of project identity and contribution signals. If you build with it, keep cryptographic authorship, code review and repository state separate.
What changes when you actually use it
For you, NIP-34: git stuff is felt when a post becomes a durable object: article, file, image, video, audio, bookmark, wiki entry or source reference. The question is whether the work still makes sense after one app, host or relay disappears. The concrete pieces kind 1621, kind 1617, kind 1618, git, draft, t decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-34: git stuff is context preservation. Store enough title, tag, author, hash, URL, media, preview and reference material that another interface can rebuild the object. If your feature depends on a private database to make sense, the NIP is not doing the portability work yet.
What the official file makes concrete
The official file is organized around Repository announcements, Nostr Clone URL format, Repository state announcements, Patches and Pull Requests (PRs), Patches, Pull Requests, Pull Request Updates, Issues. Inspect kind 1621, kind 1617, kind 1618, git, draft, t, git clone, clone because these are the pieces most likely to surface as product behavior. Read it beside NIP-10, NIP-22, NIP-65, NIP-B7 before treating it as isolated.
NIP-34: git stuff protects context. Titles, media, hashes, source links, timestamps and references decide whether work survives beyond one app.
Where it breaks
The failure mode in NIP-34: git stuff is link rot with a nice interface. Media disappears, metadata lies, source URLs change, hashes are missing or an article loses its addressable identity. The page needs to make durability part of the feature, not an afterthought.
Where this appears outside the markdown
In the ecosystem, NIP-34: git stuff is part of the creator and archive layer. It decides whether writing, media, files, bookmarks, wiki material or source references remain understandable after the first app disappears. That is why media standards need to talk about storage, provenance and recovery, not only presentation.
The nearby-standard trap
The nearby-standard trap in NIP-34: git stuff is flattening every creative object into a note with a link. Articles, videos, files, torrents, highlights, images, wiki entries and bookmarks carry different metadata and storage pressure. Read NIP-10, NIP-22, NIP-65, NIP-B7 so the product does not throw away the part that made the object portable.
Language that keeps the feature honest
Good product copy for NIP-34: git stuff names the object and the storage. It says article, file, image, video, bookmark, wiki page, torrent, highlight or podcast episode, then tells you where the signed metadata ends and where external hosting begins.
What this page does not promise
NIP-34: git stuff does not guarantee that published work survives forever. It can carry richer metadata, hashes, references or addressability, but files still need hosts, relays still need retention, and clients still need to render the object faithfully. Treat the NIP as the signed map of the work, then check where the actual bytes, previews and source links live.
Read it as a field test
Start NIP-34: git stuff with the object you want to keep: article, file, media, bookmark, repository, torrent, wiki entry or podcast episode. Then trace which parts are signed, which parts are hosted, and which parts another client can reconstruct from kind 1621, kind 1617, kind 1618, git, draft, t. That is the difference between portable publishing and a pretty link preview.
Where the standard earns trust
The source links give you places to test the interpretation in public: GitWorkshop / ngit about page, DanConwayDev ngit-grasp, GitWorkshop GitHub repository, n34 CLI. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-34 source is the anchor for exact wording, and NIP-34 commit history shows how that wording moved over time. The strongest secondary clues here are GitWorkshop / ngit about page, DanConwayDev ngit-grasp, GitWorkshop GitHub repository. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-34: git stuff: first the human promise, then kind 1621, kind 1617, kind 1618, git, draft, t, then the implementation record, then the real-world failure case. That order keeps NIP-34 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Where do the signed metadata and the actual media or file bytes part ways?
- Can the object still be identified by hash, address, title, author and source if the first URL breaks?
- Does a second client know enough from
kind 1621,kind 1617,kind 1618,gitto render the work without private context?
What to verify before you rely on it
- Find
kind 1621,kind 1617,kind 1618,git,draftin the official file and check where the UI exposes the same concept. - Read NIP-10, NIP-22, NIP-65, NIP-B7 as context before treating NIP-34 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-34: git stuff in that order: Official NIP-34 source for the current wording; NIP-34 commit history for the change record; GitWorkshop / ngit about page, DanConwayDev ngit-grasp, GitWorkshop GitHub repository for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
