GRASP: Git hosting without the gatekeeper
ngit lets you collaborate with Git without handing your project's identity to a forge. GRASP, Git Relays Authorised via Signed-Nostr Proofs, is the hosting protocol that makes that promise practical.
A GRASP service brings together a Nostr relay and an ordinary Git Smart HTTP server. It learns which repositories to serve from signed announcements, accepts Git data authorised by signed repository state, and keeps the code and its collaboration events available together.
Your keys define the project. Your signed refs define its state. A hosting provider makes that state available, but it does not get to become the project.
The power behind ngit
ngit provides the familiar workflow. GRASP gives that workflow somewhere to land without rebuilding the central forge underneath it.
| Layer | What it contributes |
|---|---|
| ngit | Familiar git clone, git fetch, git push, issue, and pull request workflows |
| Nostr and NIP-34 | Portable identity, repository discovery, signed refs, and collaboration events |
| GRASP | Git hosting that follows those signed announcements and refs |
When you run ngit init, ngit publishes a signed repository announcement that names the project's maintainers, relays, and Git servers. A compatible GRASP service can turn that announcement into a working repository endpoint. On an open service that accepts the project, there is no separate forge account to create and no repository form to fill in first.
As the project changes, signed state says which commits its branches and tags should point to. The GRASP service accepts matching Git data and serves it over the standard Git protocol. A client reads the authoritative refs from Nostr, then fetches the objects from any server the repository lists.
That small shift changes who is in control: the repository tells the hosting service what is current; the hosting service does not tell the world what the repository is.
Hosting becomes a choice, not a dependency
Publish, do not provision
Repository creation starts with a signed announcement rather than an entry in one provider's database. Open community services, paid services, and a server you run yourself can all participate in the same protocol.
GRASP does not require every service to accept everything. Operators can apply quotas, payment rules, allowlists, spam controls, or community moderation. The difference is that one operator's policy does not define the protocol or own the repository identity.
Add providers, do not start over
A repository can name several Git servers and relays at once. Hosted and self-hosted infrastructure can sit side by side. Compatible services can also proactively copy accepted events and Git objects, so adding another provider can add a live replica rather than another disconnected mirror.
If one provider disappears, the signed project identity and ref history do not disappear with its account database. A maintainer can advertise replacement infrastructure while contributors continue to identify the project through the same nostr:// coordinate.
This is resilience through replaceability. Servers still fail and operators still need backups, but no single Git host has to be the permanent source of truth.
Contributions can find another route
Issues, patches, pull requests, reviews, and discussion are signed Nostr events, not rows trapped in the database beside one hosted clone. GRASP services can carry those events alongside the Git data they refer to.
An optional GRASP capability goes further: a contributor can publish the Git objects for a pull request through an alternative compatible service when the target repository's own providers are unavailable or will not host the branch. The maintainer can still discover and evaluate the proposal without forcing the contributor to create a permanent fork first.
Private does not have to mean platform-bound
GRASP also defines authenticated, read-restricted services for private repositories. Access policy still matters, and anyone authorised to read the data can copy it, but the repository model remains based on signed identity and state rather than a forge-owned account.
One core, focused extensions
The required core defines how a service connects Nostr events to Git Smart HTTP and authorises pushes from signed repository state. Optional profiles add proactive replication, deeper conversation sync, archive services, alternative pull request hosting, and private repositories.
The GRASP specification is deliberately the dry, exact layer: it contains the normative requirements imported from the pinned grasp revision. This page explains why those requirements matter.
A protocol, not a product suite
graspowns the portable protocol specifications.ngit-graspis one implementation and owns its deployment, configuration, operations, monitoring, and internal architecture docs.- Grasp Awesome lists projects that implement GRASP, including Pyramid and n34-relay, which are not yet feature-complete.
ngitand GitWorkshop are two clients, among others, that consume compatible services.
That separation is the point. Clients can improve, hosting services can compete, and operators can choose different policies without asking every project to migrate into a new world.
Where to go next
- Why ngit? explains the broader case for portable Git collaboration.
- How ngit works follows signed refs from Nostr to Git storage.
- Quickstart uses ngit to publish a repository and open a pull request.
- The GRASP specification is the normative reference for implementers.
- The ngit-grasp operator guide shows how to run one implementation.
- Private repositories covers the current GRASP-08 client and operator path.