DeGit is a decentralized Git projects hosting platform. You can join by starting a node and pointing your browser at
127.0.0.1. Then, just work with it as if it was GitHub. There is no central point of failure, since the network of DeGit nodes is run by anonymous volunteers.
To start, simply do (it uses your
.ssh/id_rsa for authentication):
$ gem install degit $ degit run
In a few seconds you can open
https://localhost:8080 and enjoy the system, which is very similar to GitHub. You can, of course, use local Git repo, which is on-fly synchronized with other DeGit nodes.
Motivation and Related Works
We are not the first who are thinking about a decentralized solution for hosting and managing of Git repositories. There were a few similar products created before (if you know anything else, please submit a pull request):
- GitChain (abandoned in 2014)
- GitTorrent (abandoned in 2015)
- Drepo (abandoned in 2018)
- Radicle (read this)
- mango (abandoned in 2016, watch this)
- ZeroNet (not exactly Git, but relevant)
- They are not 100% reliable,
- They ban users for almost no reason, and
- They are under the influence of their local governments.
It seems that the need for a decentralized solution is obvious. We believe that the community would enjoy having a platform with the following features:
- Pull requests, stars, and followers,
- GitHub-like web user interface,
- Entirely free for public and private repositories,
- Not owned by anyone,
- Moderated by the board of deputies.
How It Works?
The following principles are behind the architecture of DeGit:
- An author is the owner of a node, authenticated by his/her RSA key
- A repository is a combination of 1) Git files and 2) immutable stories
- A story is an issue, a comment, a pull request, a star, a wiki page, etc.
- Issues, PRs, and comments have hash codes instead of sequential IDs
- Each story is RSA-signed by its author
- Each node decides for itself which repositories to host
- Give-and-take principel is in place: "The more you host for me, the more I host for you"
- Commits are announced to neighbour nodes, which they can
git pulllater if they want
- Conflicts are resolved through DeGit Consensus Algorithm (see below)
- Neighbours-discovery protocol is similar to the one used in Zold
- Nodes communicate through HTTP RESTful interfaces
DeGit Consensus Algorithm based on Proof-of-Availability (PoA):
- A branch dominates during merge if the providing node is more available
- The availability of neighbours is subjectively judged by each node
- Commits from less available branches are ignored during merge
- The availability of itself is configurable (either MAX or MIN)
It is highly recommended to avoid making parallel commits to the same branch, since it may lead to inability to merge and abandonded (or lost) branches.
Here is how the data is propagated when you interact with Git on your laptop:
git commityour changes to your branches
- You do
git pushto your
- Built-in post-commit hook pushes commits to your neighbour nodes
- Some neighbours break the connection and ignore the data
- Others attempt to merge the coming data with their local repositories
- They resolve conflicts according to the Consensus Algorithm (MAX)
- You get "OK" if all conflicts are resolved in your favor, "ERROR" otherwise
This is what happens on a node:
- New commits arrive from the client
git mergethem to the existing repository
- Conflicts are resolved according to the Consensus Algorithm (MAX)
git pullall neighbours
- Conflicts are resolved according to the Consensus Algorithm (MIN)
How to Contribute?
Just give us a star and wait. We'll update this page soon.