Version control has been technically decentralized since Linus Torvalds shipped git in 2005. Every clone carries the full history. You can push and pull between arbitrary peers. There is no architectural requirement for a server at all. And yet the entire ecosystem immediately re-centralized around a handful of forges, GitHub most prominently, because the social and discovery layer that lives on top of bare git transport turned out to matter far more than the underlying model.
Grasp is a new attempt to address this gap, defining a simple protocol for hosting and discovering git repositories in a decentralized way. It joins a longer lineage of projects that have tried to solve the same problem, and the fact that this lineage is long is itself worth examining.
What Decentralized Git Actually Means
When most people say “decentralized git,” they are conflating two distinct problems. The first is transport: moving repository data between machines without going through a central host. Git already solves this. The git://, ssh://, and https:// protocols are all peer-capable. git bundle lets you package a repo into a single file and ship it via USB drive or email. Git’s native protocol is well-documented and there are remote helper hooks for writing entirely custom transports in any language.
The second problem is discovery and identity: how do you find a repository, verify who published it, and coordinate with other contributors without a central namespace? This is where every “decentralized git” project lives and where the hard problems are.
Grasp’s framing as a “simple protocol” suggests it is aiming at the minimal viable version of this second problem, rather than trying to replace the entire forge ecosystem at once.
The Prior Art
The most serious prior attempt is Radicle, which has been in active development since around 2018. Radicle builds a full peer-to-peer code collaboration layer on top of git: repositories are addressed by cryptographic identifiers derived from public keys, gossip-based replication propagates data through a network of nodes, and social primitives like issues and patches are stored as git objects rather than in a central database. The technical architecture is genuinely interesting. Radicle uses a custom peer-to-peer network protocol called Heartwood (a rewrite of their earlier stack), and repositories get URIs like rad:z6MksFqXN3Yhqk8pTJdUGLwATkRfQvwZXygqdy1BDDHnE3Z5.
Radicle’s problem is not the technology. It is adoption. Running a Radicle node requires more operational overhead than pushing to GitHub, the tooling has historically been rough around the edges, and the social network effects that make forges useful (browsing, discovery, contribution) are absent unless a critical mass of users participate. Radicle has been iterating on this for years and still has not achieved broad adoption outside of certain cypherpunk-adjacent circles.
Before Radicle, there was Fossil, which takes a different approach: it bundles version control, bug tracking, wiki, and a web interface into a single self-hostable binary. Fossil is the VCS used for SQLite. It is genuinely decentralized in that every clone contains the full project state including tickets and wiki pages, and sync is bidirectional between any two nodes. But Fossil chose not to be git-compatible, which has kept it a niche tool despite being technically well-designed.
There is also git-ssb, which layered git hosting on top of Secure Scuttlebutt. SSB is a fascinating offline-first gossip protocol where identity is a cryptographic keypair and data propagates through social graphs. Git-ssb worked but depended on the SSB ecosystem, which itself never reached critical mass.
Where Grasp Fits
The framing around grasp being “simple” is a meaningful signal. The pattern in this space is that ambitious full-stack replacements tend to stall because they require everyone to adopt a new runtime, new identity system, and new social conventions simultaneously. A minimal protocol that layers on top of existing git infrastructure and existing HTTP has a better chance of incremental adoption.
A simple decentralized git protocol likely works roughly like this: repositories are published at well-known HTTP endpoints, addressed by some combination of a public key fingerprint or content hash, and the protocol specifies how to resolve these identifiers to actual transport URLs. The resolution could be done via DNS TXT records, a DHT lookup, a flat text file, or something similarly low-tech. Once you can resolve an identifier to a URL, you fall back to vanilla git transport, which means every existing git client works without modification.
This approach trades the full ambitions of Radicle for something that a single developer can implement over a weekend and that requires no new software on the cloning side. The cost is that it does not solve the social layer problem at all: there is still no decentralized issue tracker, no pull request mechanism, no notification system. You get resilient repository hosting, not a GitHub replacement.
The Email Parallel
There is a useful parallel with email here. Email is a genuinely federated protocol where anyone can run a server, and yet in practice a small number of large providers handle the vast majority of traffic because the operational costs and deliverability problems of self-hosting are too high for most individuals. Git hosting is similar: the protocol allows decentralization, but convenience gravity pulls everything toward hosted services.
The projects that have partially escaped this gravity tend to share a few characteristics. They target developers who already have opinions about self-sovereignty, they make the default setup genuinely easy (a single binary, clear documentation, sensible defaults), and they do not require participants to abandon their existing workflows entirely. The Forgejo and Gitea ecosystems have had more success than pure P2P approaches, because they preserve the familiar forge model while enabling self-hosting and, increasingly, federation via ActivityPub through the ForgeFed protocol.
What Would Actually Change Adoption
The technical problem of decentralized git is mostly solved. What would move the needle on adoption is something much less glamorous: tooling quality. Radicle’s biggest obstacle has never been the protocol, it has been that rad commands are unfamiliar, error messages are opaque, and the mental model for how identities and repositories relate is non-obvious to someone coming from GitHub.
A decentralized git protocol that works via regular git remote helpers, uses existing SSH keys for identity, and requires no new CLI tooling to clone would have an adoption path that Radicle does not. You would just add a remote URL with an unfamiliar scheme, and git would handle the rest via a small helper binary.
Grasp’s minimalism is, in this light, a genuine strategic choice rather than a limitation. Protocols that do less tend to interoperate better, attract implementation diversity, and survive long enough to develop real user communities. The comparison to gemini is apt: a stripped-down protocol that explicitly scopes out complexity in order to remain implementable by a single person in an afternoon has a different adoption curve than a comprehensive architecture designed by committee.
The Verdict
Whether grasp specifically catches on depends on details I cannot evaluate without running it: how the identifier resolution actually works, what the failure modes are, whether the documentation is good enough for someone to self-host in under an hour. Those details matter enormously in this space.
What I can say is that the approach of defining a minimal protocol rather than a full platform is the right instinct. The decentralized git ecosystem does not need another ambitious project that tries to replace GitHub wholesale. It needs boring infrastructure that works reliably, composes with existing tools, and makes self-hosting a reasonable option for people who are not already ideologically committed to decentralization.
If grasp is that, it is worth watching. The git hosting space is ready for something that lowers the floor without trying to raise the ceiling all at once.