About

gitworkshop.dev and ngit are tools to enable code collaboration over nostr created and maintained by DanConwayDev

they implement the nip34 draft, which ports the git-email-patch model to nostr, and also have backwards compatible enhancements (nip34+ for shorthand) eg. to optionally enable experiences similar to github PRs

gitworkshop.dev aims to support all things git on nostr, such as the yet to be released and NostrNest and gnostr. ngit is more opinionated focusing on nip34+

should we focus on improving the PR-like experiences or remove them in favor of traditional patch-model patch application? please let use know!

The Need

git is decentralized version control system, yet most freedom tech projects use centralized walled gardens on top of git as a social and collaboration layer for code changes

by far the most popular, Microsoft's GitHub, has a history of banning accounts and repositories without warning and this creates a real risk of disruption for important projects like bitcoin-core

The Opportunity

whilst alternatives do exist, nearly all of them involve moving to an another walled garden, either controlled by a different centralized guardian, or self-hosted which is less suitable for a anarchic project

some projects use patches-over-email: an alternative and decentralized approach that pre-dates GitHub. despite its antiquated tooling, it has a very smooth and effective workflow for those that use it regularly and has proven to scale to very large projects like the linux kernal.

ultimately, GitHub remains by far the most popular choice for freedom tech projects. The accessible UX, convenience, inter-connected tooling and network effect are just a few of the reasons

nostr is the ideal permissionless, decentralized and censorship resistant social layer for the anarchic FOSS code collaboration use case

there is an opportunity to build modern tooling that compete from a UX perspective and have the additional benefit of integrating into a wider social ecosystem

The Philosophy

there is innovation happening with git and nostr in a few places and gitworkshop.dev aims to work with different approaches

ngit is more opinionated and its philosophy can be summed up as:

• let git be git - don't try and reinvent git
• let nostr be nostr - leverage the benefits of nostr
• learn from the success of others - eg. the PR model has proved to be very popular. how can we enable similar experiences with patches?

patch-over-email, with its proven scalability, lays the foundation for providing this social layer without having to re-invent the complexities of creating an efficient alternative to git server over nostr, or use specialized relays

The Protocol

nip34 is draft nip (nostr protocol) for sending git patches over nostr, similar to how patches are sent via email using `git format-patch` and `git send-email`. The patches-over-email model has proven to be a robust workflow that is used extensively; including in very large project such as the linux kernel

ngit and gitworkshop.dev are experimenting with some additional, backwards compatible features (nip34+ for shorthand), some of which may make it into the nip34 specification:

• patches optionally managed as branches, similar to GitHub PRs
  • amendments to a proposal can be made by pushing a commit using ngit push rather than issuing a complete revision, which modifies the original commits (still possible with ngit push --force or ngit send --in-reply-to nevent123...)
  • proposal can be checked out as a branch which reflects the repo state when the proposal was generated with pgp signatures intact
    • there is less friction for reviewers with this model as they don't have to deal with resolving conflicts as patches are applied to the tip of the main branch. whereas maintainers, who might be considering accepting the proposal right away, may find it preferable to resolves conflicts as part of their review
  • author pgp signatures and original commit_ids can be retained
  • features can be 'merged' using a 'merge commit' so that a series of feature commits can remain distinct rather than each applied to the main branch directly.
• multiple maintainers for a repository and a pathway to smoothly transition maintainership when a maintainer moves on
• ensure that user who have already cloned the repository dont get scammed by someone else issuing a repository event, pretending to be the maintainer, and directing users to a malicious git server
  • ngit init creates an optional maintainers.yaml file in the root of your repo that lists the authorized maintainers and desired relays
    • a fallback is used to prevent contributors from needing to know the event id if a maintainer is not ready to add a nostr specific file to the repository. ngit tags the earliest unique commit id in the repo event. ngit defaults to uses the most recent repo event it finds with this tag. it also tags all proposals with this id and when listing patches, also includes patches sent to other repo events with this id as it is clearly intended for the same repo.

FAQs

Your not replacing GitHub, your still using it GitHub as a git server.

it is trivial to switch git servers as they all operate the exact same protocol. changing the social layer requires a social and UX shift which can be challenging, disruptive and timeconsuming.

are you trying to replicate / replace Github?

no. GitHub is a very large product with a lot of features which don't meet the goal of freedom tech code collaboration.

we are specifically looking to address the needs of anarchic FOSS freedom tech products

Enhancements

got ideas? please share them and lets explore as a community. here's three to get you started:

• DVM to run CI pipelines? yes please
• services to enable merge directly from nostr events. hello!
• repo event showing authoritive tip of main branch and referencing multiple git_server mirros? Hell yeah!