Inspiration
Every developer's workflow runs through a central service like GitHub or GitLab. Meaning a single central company holding the source of truth for an enormous fraction of the world's code, has the power to deplatform projects, throttle access, or just go down. Git itself was designed to be distributed, but the social and collaboration layer collapsed back into a central server. We wanted to see if we could close that gap: keep the git workflow developers already know, but rip out the central server entirely, while also solving a secret management problem that has led to companies like Vercel getting breached and compromised.
What it does
GitTorrent is a decentralized git remote. You push to a peer-to-peer swarm instead of a server, and every authorized collaborator holds a full replica of the repo. This means you can directly use commands such as git clone, git push, git pull, etc like normal on a gittorrent://ab123 URL.
How we built it:
The trick is that Git already supports custom remote helpers. When set up, from git's presepective gittorrent://xxx URL is just another remote.
The system is layered on top of four Hyper primitives:
- Object storage. When you push, the helper walks the new commits, packs each git object (commit, tree, blob), gzip-compresses it, and stores it in a Hyperbee, keyed by SHA. Clones fetch objects out of the Hyperbee and write them as loose objects into .git/objects/.
- Ref state. Ref updates are appended as signed operations to an Autobase log, a multi-writer CRDT where every peer replicates every writer's feed. Autobase applies all ops deterministically (ordered by timestamp and key), so the shared ref state converges across all peers without a coordinator.
- Discovery. Peers find each other through Hyperswarm's DHT, using the repo key as the topic.
- Local storage. Each repo lives in a Corestore at ~/.gittorrent/stores//.
For collaboration, the person who runs pear-git init becomes the sole writer. They invite others by appending an add-writer op signed with their ed25519 key. Only indexers can invite or revoke; non-indexer writers can push code but can't modify the access list.
Challenges we ran into
This was our first time working with P2P networks, Pear's tools, and Tauri in Rust (our chosen desktop app framework). One of the major issues was that it appears the certain routing and Wi-Fi configurations of the university network interfered with the Peer-to-Peer connections.
Accomplishments that we're proud of
Overcoming challenges in the ideation phase to land on an idea that applies P2P networks in a useful way that enhances current tools.
What we learned
How to use Pear's tools to develop an interesting and useful application of P2P technologies and understanding more about the uses of web3.
What's next for gittorrent
Our goal is not only to make gittorrent safer and decentralized with all the features of GitHub, but took make it have significant features that developers value that GitHub lacks, like secure secret management. This will mean we can onboard both power user developers and novice developers/hobbyist users.
Built With
- javascript
- pear
- rust
- shell
- tauri
Log in or sign up for Devpost to join the conversation.