GitTor - A Decentralized Git Hosting Platform

Project Overview

A decentralized Git hosting platform where repositories are synchronized between users via a P2P protocol using torrenting. The purpose of this application is to eliminate the issue of a single point of failure, which affects other platforms such as GitHub and GitLab. The problems that users have identified with this approach are as follows:

1. If the hosting platform goes down, there is no automatic fallback, meaning collaboration on a project is completely halted until an alternative means of sharing is implemented. The switch from one hosting platform to another can take anywhere from a few hours to a few days, depending on the scale and complexity of a project.
2. When cloning a repository, the hosting platform can trivially add/remove any commits from the top of the log without it being obvious. The "author" and commit messages can be identical to the actual state of the repository, with the only difference being the repository content and commit hashes. Something that, in large projects, is rarely checked in depth.
3. By default, Git uses SHA-1 for commit hashes, which has been broken. With enough time and computing power, both of which Microsoft (the owner of GitHub) has, a commit hash collision could be found to inject malicious code in the middle of a project's history. This tactic would be even more challenging to identify than the last, since it can occur at any point in the project's log, not just at the top, and the only difference would be the repository contents.
4. Finally, when the hosting platform is your only means of collaboration, they are the judge, jury, and executioner. Even if they don't change the state of your repositories, they can decide to block your commits, make terrible commits in your name, or delete your repositories (ideally, you would still have an instance on your machine).

To address all of these issues, we aim to minimize the power of the hosting platform as much as possible. Instead of hosting your repository through GitHub or GitLab, you and everyone who contributes to it will host the repository and share it with others via a P2P protocol. When sharing the repository, your computer will seed it with a .torrent file. By sharing this .torrent file with someone else, they will be able to leech the repository, downloading it directly from you.

This strategy clearly resolves issue one; even if your computer is off, others can seed the repository, allowing anyone with the .torrent file to leech it. The solutions to two and three are less clear. The .torrent file contains the hash of the contents, among other things. By using this to share repositories, any peer that downloads the repository can verify that every byte matches the original, no matter which seeder it came from. Lastly, we must address issue four. Since you are the one hosting the repository (along with everyone else who has access to it), you are the judge, jury, and executioner. You control the state of the repository, and it is up to the other contributors to decide if they wish to leech your changes and work off of them.

However, this approach is not without some of its own concerns that need to be addressed. The primary problem with this new approach is how to share changes to a repository among the contributors. Since any change to the repository would result in a different .torrent file, the new file needs to be shared with all contributors. While this can be done by any means, email, paper, or even carrier pigeon, none of these would be convenient for GitTor users. Instead, we will create a web application that allows users to find, view, and obtain .torrent files for repositories. The difference between this and a typical hosting platform is that its power is significantly limited, as it has no control over the repository contents. Additionally, a simple, documented API will be available, allowing alternatives to be easily created and switched to in minutes.

Another concern is that anyone with access to the repository could modify it, and there would be no way to restrict write access to verified contributors other than through the web application, which we want to limit its power as much as possible. To ensure that only authorized individuals can commit to a repository, a file in the repository will store the public GPG keys of those allowed to commit, which can be used to verify the validity of the repository. To add another contributor, an already verified contributor must add the new contributor's GPG key to the file. When a new GitTor repository is initialized, it will initially contain only the creator's GPG key.

To summarize, the overall structure of this project is two parts:

1. A command-line tool that allows users to easily publish the new state of their repository and seed it for other users to leech. The command-line tool will also enable users to leech a repository and validate the commits via the GPG signatures and the valid contributor's keys file.
2. A web application for users to publish their .torrent files to and see other users' repositories with contents and pull requests. The application should also validate the signatures when people publish a new .torrent file and start seeding the repository itself.

As for the tools we intend to be using:

• CLI:
• C for the source code
• Many C libraries, such as libcurl, glib, argp, libtorrent, etc.
• Unity C testing library with Gcovr coverage reports and Valgrind memory analysis
• CppLint, Clang-Tidy, and Clang-Format rules
• Pipeline for rule checks, tests, reports, and builds
• Web App:
• API:
• Spring Boot Java source code
• JUnit integration and unit testing with JaCoCo coverage reports and context profiling
• Autogenerated OpenAPI specification with documentation
• Checkstyle rules
• UI:
• Angular 20 source code
• Nginx runtime with reverse proxy to API
• Cypress end-to-end testing
• Tailwind styling with ZardUI component library
• Autogenerated API connection code via OpenAPI specification
• Prettier and ESLint rules
• A PostgreSQL relational database
• A MinIO Simple Storage Service
• Docker Compose for a Dockerized application stack
• Pipeline for rule checks, tests, reports, and builds