grasp: a simple protocol for decentralized git
A simple protocol for code collaboration that uses<br>interoperable servers and clients
In Grasp every user identity is a cryptographic keypair and doesn't depend on anyone;<br>every code state is signed; git servers that speak Grasp can be hosted anywhere,<br>seamlessly used by many and don't have to be trusted; repositories can migrate<br>seamlessly; issues and patches can flow freely.
Follow quickstart<br>See compatible software
No accounts, no sign up forms
No need to sign up anywhere, anyone can start publishing from the CLI with free<br>unlimited identities (as long as there is a server that accepts you)
Full interoperability
People running personal servers can freely interact with people who rely on<br>third-party servers. It doesn't really matter where the code is hosted.
Send patches easily
Without complicated sign ups and click-ops, sending small contributions to other<br>people's code is often a single command.
Run your own server easily
Whether you want to host only your own code or code from your community, or even<br>charge money to host code from others, everybody is still in the same ecosystem.
Custom moderation
Whether you're running your own server or using someone else's, the server can impose<br>any moderation criteria it wants, and the client-side can augment it.
Issues, branch merge requests and more
Built-in issue filing and management with threaded discussions based on signed<br>messages and pull request flow for more complex code contributions.
Short tutorial
Getting started with
nak
nak is a command-line tool that wraps the basic remote functionalities of<br>git remotes for Grasp, but also provides an interface to issues and patches;<br>install.
1) Publish a repository
git init my-project<br>cd my-project<br>git add .<br>git commit -m "initial commit"
nak git init --owner --identifier my-project --name "my-project" --description "Example NIP-34 repo"<br>nak git sync<br>nak git push
2) Send a patch
git checkout -b fix/readme-typo<br>nvim README.md<br>git add README.md<br>git commit -m "fix: correct README wording"
nak git patch send HEAD^
3) Fetch and apply patches
nak git patch<br>nak git patch 7ef59e<br>nak git patch apply 7ef59e
4) Open and discuss issues
nak git issue create<br>nak git issue<br>nak git issue cb44d2<br>nak git issue reply cb44d2
5) Clone from a GRASP reference
nak git clone /my-project
1) Clone a repository the normal git way
git clone nostr:///<br>cd
2) Submit a PR from a `pr/` branch
git checkout -b pr/great-feature<br>git commit -am "improve the world"<br>git push -u
# for cover letters and extra options<br>ngit send
3) View open PRs as remote branches
git branch -r --list origin/pr/*
# or inspect them with ngit<br>ngit list
4) Update the same PR by pushing more commits
git commit -am "extra thing"<br>git push
5) Initialize or merge as a maintainer
git init my-project<br>cd my-project<br>git add .<br>git commit -m "initial commit"<br>ngit init
git checkout master<br>git merge pr/great-feature(e8246b2)<br>git push
The solution isn't another centralized platform
GitHub made collaboration mainstream, but it has<br>become a huge bottleneck, liability and central point of failure, not to mention the<br>censorship. Getting everybody to migrate to<br>GitLab or<br>Codeberg is not the solution.
Self-hosting with Gitea or<br>Forgejo can be a good fit for private teams or<br>closed organizations, but for public open-source isolated forges fragment discovery,<br>duplicate identity and account setup and make cross-project contribution harder and<br>more annoying.
Grasp offers a protocol-centric model: many<br>frontends, many CLIs, many server implementations, all interoperable around a standard<br>for cryptographically signed identities and messages that are sent to and read from<br>the same servers that host the git repositories.
How Grasp works
Once you have a local git repository and a keypair you can<br>sign a message announcing that repository and<br>another message announcing the state of its branches.
Once you publish those messages to your list of<br>chosen servers, those servers will be able to<br>accept your git repository as long as it matches the announced state.
The announcement message can also be published to other servers that can act as<br>aggregators where users can discover your<br>projects.
On every new commit you sign a new repository state message and everything gets<br>updated on your chosen servers. Anyone following you or your repository for updates<br>can be get immediately notified.
Issues and<br>patches are just other kinds of standardized<br>messages that can be sent by anyone directly to your servers, so you can read them<br>whenever you want, apply the patches or respond to the issues. These same servers may<br>choose any criteria to<br>filter out spam or inconvenient contributions<br>they want.
While patches work similar to the old<br>git-send-email approach, pull requests are more<br>like the centralized forge approach: you publish your branch to a Grasp server then<br>send a message to the target asking them to pull the branch and...