If your project lives on GitHub, now is a good time to seriously consider hosting copies of your repositories on nostr. And by the end of reading this, you'll know how.
Using nostr-based alternatives to GitHub, such as ngit/GRASP, ensures that you won't be in as much trouble the next time GitHub goes down for hours, like it did three times in August of 2026 alone.
Solely relying on GitHub is especially risky if your project is deemed problematic by certain powerful people. We've seen this play out just this past July when the Indian government ordered GitHub to geoblock the Bitchat repository. And it is exactly for addressing scenarios like these that Dan Conway has spent the last few years building on nostr. Within days of the order, Bitchat copies were up on ngit, and on many more.
One month before that, GitHub banned a few rust-lightning contributors and deleted their pull requests (which can never be recovered) for no valid reasons. Sadly, whenever a project gets banned like this, it usually only starts a game of musical chairs that swaps one centralized problem for another. As Dan puts it: "That's not freedom technology."
When I embarked on this journey I would never have dreamed that GitHub would not only fail to adapt to the evolving landscape but would let their existing services degrade so much as the demand profile changed.
Microsoft, which Dan calls a behemoth, owns GitHub and uses it to hold the open source world in its grip. To be fair, GitHub has been amazing for open source; it became the home of FOSS because it served the community so well, so much so that people are leaving it with tears in their eyes. The problem is structural: GitHub is a platform, not a protocol. A platform is a system of control that serves its own interests, whereas a protocol is a freedom-maximising foundation that can't rug you. But now that we have nostr, there is a real way out. One that doesn't make us fall back into the same old traps.
As Walter Wink, whom Dan is very much inspired by, wrote:
Evil can be opposed without being mirrored. Oppressors can be resisted without being emulated. Enemies can be neutralized without being destroyed.
We don't need to stop using GitHub; we just need to use tools like ngit/GRASP that nobody owns. Dan has also built GitWorkshop.dev to make everything more user-friendly:
Change is here, now time for acceleration. The open source world was never meant to be shackled to one company's server. So how did we all end up with most of our code sitting on Microsoft servers? Well, it all began with Git.
Git & GitHub 101
Git is a distributed version control system: every copy of a project carries its whole history, and any copy can sync with any other, on any server. What Git never came with is a place to discuss the work.
Linus Torvalds built Git specifically for the Linux team in 2005, after something eerily familiar had happened to him… He had made the controversial choice of running the kernel's workflow on a closed-source tool. One day, the man who owned the license changed his mind and revoked their right to use it. The Linux team had no other choice but to write their own: Git.
Git in itself is a state chain. Every commit id is a hash of all previous changes.
But it just wasn't very user-friendly, or even practical for a lot of people. That's where GitHub saw an opportunity for a new way to use Git based on open collaboration.
On GitHub, anyone can suggest changes to any public project and fork their own copy, and the maintainer decides whether or not to accept them.
Not only that, but reading pull requests on the terminal is not everyone's cup of tea, whereas anybody can easily read a webpage like GitHub's that shows you every code change inline, with comments, threads, review states. It's just too convenient.
But convenience always comes at a price. One that the Linux team, for instance, never agreed to pay. To this day, they still use the email model to review patches.
The code has always been able to go anywhere; that's what Git is. It's everything else that's the problem: the comments, the PRs, the CI, the follows, the stars and basically every communication around the code is just a row in GitHub's database. And it's precisely those things that happen to help you gain credibility online as a developer.
That's why migrating away from GitHub has always been too much of an inconvenience. So much so that for the best part of the last two decades there was not even a question about where a new project would go: it would obviously live on GitHub. Where else? That's pretty much where everyone in software development has been since 2008.
This level of network effect that GitHub had was so impossible to replicate (until today) that competitors just gave up. Google Code closed shop and told their users to migrate over to GitHub, and so did Microsoft, as their CodePlex faced the exact same fate. Soon, the acquisition path became their only hope. Microsoft's offer was just too good to refuse: an estimated 25 times GitHub's annual revenue that year. Peanuts considering how desperate Microsoft actually was to get back into developers' good graces after having antagonized open source so long.
For Dan, the cringiest part about this whole ordeal is GitHub restricting FOSS contributors in places like Iran, Syria and Crimea, and blocking tools that help the powerless defend themselves against the powerful, like Bitchat in India, at the behest of governments. Others are angrier about how Microsoft built their proprietary Copilot AI-assistant based on all of the code that was hosted on GitHub. The Software Freedom Conservancy quit GitHub over Copilot and urged all free-software projects to do the same. Other developers took Copilot to court for stripping their code of its licenses and selling it back at a premium, a case that's still being argued as of today.
But now that we finally have pseudonymous identities that are cryptographic key pairs (a private key only you hold, and a public key everyone else knows you by) there's no reason that our social network and street credibility shouldn't be controlled and owned solely by us: the users. That is the idea Dan has spent the last three years turning into properly working, free and open source software, one that puts social identity back in the hands of users instead of platforms. But who is Dan, really?
#danstr
The first time that I got to meet Dan, he told me about his daughters learning binary and about the pride that he felt watching them spell their names in ones and zeros. It made me curious about who he was as a person, and how that reflects into how he builds what he builds.
He clearly understands how technology can help put more of that power back into people's own hands, and it's perhaps because of that, that his adversarial mind cannot stop thinking:
If you're going to be using tools and working on tools that the established powers are going to see as a threat, then [it helps to] do so privately... one of the best ways that you can defend yourself against powerful actors [is] for them not to know you exist.
Good people sometimes need defending against the very system that's supposed to protect them. And nowadays, digital privacy is often a matter of survival for people in those situations. Because it's never good news to rub very powerful and rich people the wrong way. Especially when you're not nearly as rich or powerful yourself. That is why Dan is so passionate about what he does; it's a real shot at turning the tables on a power asymmetry as old as time.
What excites me about cryptography is that it enables the weak to defend themselves against the powerful.
Those who interpret and enforce the law are not always right, and sometimes even the law itself is wrong. But that, history only ever admits in hindsight. The reality is that we need to be humble about our present view.
Let's not forget that only 30 years ago, the US government classified strong encryption as a munition, the same munitions list as missiles. They opened a criminal investigation into Phil Zimmermann just because he published encryption software. Ultimately, the case was dropped in 1996, and within a decade the same cryptography could be found in every browser on earth.
Similar story in August 2022. Within hours of OFAC sanctioning Tornado Cash, GitHub suspended the project's organization and the personal accounts of its developers. None of them were even on the sanctions list. Then two years later, a federal appeals court ruled the sanction itself unlawful.
Satoshi chose to remain anonymous for a pretty good reason.
We have a duty of care to the users to keep private information private.
Dan used to work as an IT management consultant and he had a long commute, a perfect time to listen to plenty of freedom tech podcasts. For years, he just watched from the sidelines, waiting for his chance to contribute. Eventually, he started picking up bounties after his kids' bedtime.
He first considered making his big jump by contributing to cross-input signature aggregation, a change that would make private bitcoin transactions cheaper. Then, in April of 2023, Jack Dorsey started rethinking the funding model for a series of bounties that he had put up for a nostr-based GitHub replacement, a problem Dan already cared about. Back in February, he'd told fiatjaf: "The github usecase really appeals. But that's a big project with a lot of considerations and I thought I probably should [do] something small first." So he replied to Jack:
The technical challenge interests him, sure. But what really motivates him the most is empowering people to build and collaborate without permission, so that no third party can ever lock anyone out. And in a way that I did not expect:
I was skeptical about whether it would work, but I thought it was an interesting problem; I wanted to work on the problem.
It takes a rare kind of person to get excited about working on a problem specifically because they doubt it can be solved. Dan calls it the difference between a job and a vocation:
I feel profoundly grateful that I'm being paid well to build the future I want to live in.
He could have stayed working in consulting, with actual coworkers that he could have lunch with in person. Instead he's talking with other online nostriches, alone at the computer, just working on making open source better. We're lucky to have him.
A year of Dan's proof of work, from OpenSats' heartbeat page.
And he may have lost the camaraderie of his coworkers, but he sure gained a nostrverse full of people on the same mission, contributing to each other's projects. Hopefully, that has made it worth it for him. Especially since the feedback from the nostr community appears to have always been so instrumental to Dan's software development loop: thinking out loud all together over nostr, building, shipping, and thinking out loud some more.
Software development is fundamentally a social experience and this is where nostr shines.
How ngit and GRASP came to be
In April 2023, Dan was posting about whether nostr could liberate the world's code collaboration from centralized authorities. One month later, the first ngit commit in history was made.
The first iteration was a full-blown nostr-maximalism edition: nostr was doing just everything. Every version of every file in the repository was stored as a nostr event, and every reader had to download every single one of them. As it turns out, it just couldn't scale.
Dan went back to the drawing board and, in September 2023, he began a ground-up redesign based off of one newly understood principle:
So that's why in ngit, now, you'll find that Git keeps the code, and that nostr carries all of the communication between people (i.e. the pull requests, the issues, the comments, and the signed notes from the maintainer saying which commit is the real one).
In July of 2023, OpenSats started funding Dan's work for ngit.
Over the winter of 2023-2024, Dan helped build NIP-34, which is the standard for git over nostr. And then in spring:
He got a new grant again in November 2025 for GRASP.
In June of 2025, the first version of GRASP shipped. Then, Dan rebuilt it from scratch over the winter, as he apparently tends to do. Fast-forward to today, and v3 of ngit and v4 of GitWorkshop.dev just launched. You can now have private repositories and moderation run by the maintainer. He recently posted on nostr about how he had spent the last three years crafting ngit by hand, and the past eight months using AI in his workflow. When I asked him about it, he wrote:
For a while, I was pessimistic about the role of AI partly because it displaced my skills as a coder, which formed not a small part of my own personal identity, but mainly because of the prospect of the best models being controlled and permissioned by a small number of powerful institutions and the privacy nightmare of feeding all our conversations into their data lake.
I'm heartened to see how quickly open source models are catching up. What excites me about cryptography is that it enables the weak to defend themselves against the powerful. AI may become a tool with these same properties.
In late July, his AI agent's first pull request got merged. It has a nostr keypair of its own. The agent writes code and opens pull requests like any contributor. It can't merge anything; every change is still only merged under Dan's key.
The bot recently did its first pull request to the CI and signed software releases, which I personally am very excited about as it's one of the last remaining pieces that still makes it hard for users to migrate completely away from GitHub.
If you want your AI assistant to use ngit too, it's easier than counting one-two-three. I asked my agent to figure it out, published my first repository, and I had my first contributor within hours.
GitHub's network effect is no longer irreproducible. Now it's up to us to act accordingly.
ngit to GitHub Mirror Walkthrough
Which brings us back to the most minimal action we can do today to achieve the maximum results: let's create mirrors. When we're done, your repository will not only live on GitHub but also on two GRASP servers over nostr. So that just one git push updates all three.
Let's first have a look at all the pieces, and then walk through each of the four commands required.
Quick cheat-sheet:
- ngit: the command-line tool that connects Git to nostr
- Git Relays Authorized via Signed-Nostr Proofs (GRASP): hosts the repositories
- GitWorkshop.dev: the first web client
- Git: stores the code, every version of it
- nostr: carries the signatures, issues, PRs, and comments
Now let's go.
Tutorial
Ok, so first things first. Get git and curl on your terminal (on Windows, use WSL) and make sure you're inside the folder of the repository that you want to mirror (the mirror is public, even if the GitHub repository isn't).
No nostr account yet? Create your key at nstart.me first, or let ngit make one with ngit account create --name "Alice" (see the quickstart) and skip steps 2 and 3.
If you already push to GitHub over SSH, or have a personal access token you use for pushing, you're set. Otherwise, before your first push, make a personal access token for just this repository with Contents set to Read and write, and keep it in your password manager. GitHub may ask for it again on later pushes, and the push fails if the Password: prompt sits there too long.
ngit and nak both install into ~/.local/bin, so put that on your PATH first (on Linux or WSL, use ~/.bashrc instead of ~/.zshrc):
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc
1. Install ngit.
The installer will verify that it's downloaded properly, then once that's done, it will add ngit and git-remote-nostr, which teaches Git to speak nostr:// URLs:
curl -fsSL https://ngit.dev/install.sh | bash
You know it worked when you see: "Installed ngit v3.0.1".
2. Get your nostr remote signer.
Already use a remote signer like Amber? Skip to step 3 and use its bunker:// address there.
First off, I don't know who needs to hear this but: never paste your nsec anywhere! Use nak here, as it's perfect for working on the terminal. Install it with its one-liner:
curl -sSL https://raw.githubusercontent.com/fiatjaf/nak/master/install.sh | sh
Then lock your key behind a password. This asks for your nsec and a new password without showing them or saving them in your shell history, and saves the result as you.ncryptsec in your home folder, outside your repository:
printf 'your nsec: '; read -rs NSEC; echo; printf 'new password: '; read -rs PW; echo; nak key encrypt "$NSEC" "$PW" > ~/you.ncryptsec; unset NSEC PW
Then check that the file really holds your key. It asks for the password again and prints your npub, make sure it's yours (if you get failed to decrypt instead, something got mistyped, just run the lock command again):
printf 'password: '; read -rs PW; echo; nak key decrypt "$(cat ~/you.ncryptsec)" "$PW" | nak key public | nak encode npub; unset PW
After that you can start a bunker, and just make sure that you leave it running, step 3, step 4 and every git push after that need it (next time, just run this same command again):
nak bunker --sec "$(cat ~/you.ncryptsec)" --profile you wss://nos.lol
It worked when nak asks for your password and then prints a bunker:// address. Make sure to check that the printed npub is yours; if it isn't, stop, run rm ~/.config/nak/bunker/you, and redo the lock step.
3. Sign this repository from a second terminal, again inside your project's folder.
If you're paranoid, don't ever use --nsec, because otherwise your private key gets written into your shell history in plain text. That's the nice thing with nak's bunker: your key never leaves that first terminal and ngit only ever receives signatures.
Paste the full address in place of bunker://..., keeping the single quotes:
ngit account login --local --bunker-url 'bunker://...'
Don't share that address: until ngit uses it, anyone who has it can sign as you.
It worked when ngit answers: "logged in to this local repository as" followed by your name (or your npub).
If it just sits at connecting to remote signer..., press Ctrl+C in both terminals, start the bunker again and log in with the new address it prints (the code at the end changes every restart). If ngit init or a git push ever hangs, Ctrl+C it, restart the bunker and run it again, no new login needed.
4. Announce the repository
There are two ways to mirror. You can let GitHub update automatically every time you push, if you want it always up to date without thinking about it. Or you can update GitHub yourself whenever you choose, as many maintainers prefer, so that it can never slow down or block a nostr push. This tutorial takes the first way, by listing GitHub as one of the repository's servers. Swap in your GitHub URL, the https://github.com/<user>/<repo>.git address from GitHub's Code button, and your project's name, then run:
ngit init --name your-project --additional-clone https://github.com/you/your-project.git -g relay.ngit.dev -g gitnostr.com -d
--additional-clone is what keeps GitHub in the loop.
-g adds free community servers.
-d accepts the defaults.
It worked when you see "share your repository:". A couple of relays failing along the way is normal. ngit pushes your code to the new servers right away and repoints origin at the nostr URL (your old GitHub remote is still there, now called github).
Now, whenever you commit, one ordinary git push feeds both GitHub and the nostr servers. If GitHub asks for a username and password (a failed over ssh line just before that is fine, it tries https next), use your GitHub username and your GitHub personal access token, not your GitHub password. Careful with that token: copy it only when you're at the Password: prompt, and paste it right there. If the GitHub part still fails, ngit sync catches GitHub up.
Ta-dah!
5. Move the conversation, not just the code.
Mirroring backs up your code, but the issues and pull requests still happen on GitHub. The real move is inviting people over:
- Put your GitWorkshop.dev link (the one after "share your repository:") at the top of your GitHub README, so people know where to file issues and pull requests.
- Anyone signed in with nostr can open an issue there, or from the terminal:
ngit issue create --subject "…" --body "…" - To send you a pull request, contributors (with ngit and a signer, steps 1–3) clone your
nostr://address, work on a branch starting withpr/, and push it:
git clone nostr://npub1<your-npub>/relay.ngit.dev/your-project
git checkout -b pr/my-fix
git push -u origin pr/my-fix
That push becomes a pull request signed by their key, ready for you to review on GitWorkshop.dev.
Thank you for reading this far, please consider mirroring one of your repositories today. Or even better, create your next project directly on ngit, free from the shackles of permissioned platforms! Found an issue in the tutorial? Contribute and fix it on GitWorkshop.dev!
You can find Dan on nostr as DanConwayDev. If you want to help us support people like him please consider setting up a recurring donation:
For comments, corrections, or suggestions about our Spotlight series, please reach out to spotlight@opensats.org.