Alpheid 🦐

A decentralised version control system using blockchain technology.

Caution

This project is at its infancy so no actual code yet

Rationale

Git is supposed to be a decentralised technology allowing seamless integration with other Git repositories both local and remote. However, despite these claims, more and more of Git is centralised. Big tech companies have taken over Git and most products go around the technology.

Moreover, these hosting platforms are proprietary blackboxes. We should always assume that our data is already been scraped the moment we use these kinds of services.

What does Alpheid do?

Alpheid is a decentralised version control system for Web3 and Blockchain technologies. It leverages the power of Internet Computer Protocol plus it has its own way of doing version control as compared to Git.

Version Control Theory — A Proposal

Alpheid creates a snapshot of all changes and a default traversal based on which commit has been traversed. Each change is a "branch". Unlike Git where it is basically a linear history for one branch, there are no concepts of linear branches in Alpheid. Because of this, there is no such thing as a "root" for Alpheid because each change is independent from each other. It's up to the user of Alpheid to see which commit is the "root" for them.

flowchart LR
  S[PseudoRoot] --> C[Change] --update snapshot--> N[New PseudoBranch]
  C --becomes current traversal--> Commit

when commiting changes, Alpheid will record a list of "traversals" which will be explained below.

Traversals

Traversals are a core part of Alpheid.

The idea behind traversals is because there are no such thing as "root" in Alpheid. By default, Alpheid will list a traversal for each change.

This follows a Git-like structure, the only difference, this traversal can be destroyed and modified.

A user can "tag" a traversal as they see fit. By default, the listed traversals are recorded with a default name prefixed with "punch".

Changing traversals

Alpheid allows users to change the traversals as they see fit. While they are allowed to delete the by-default recorded traversal, they are discouraged as this allows them to follow a linear history like git.

But the flexibility to choose which changes are parts of their own traversal is a powerful feature because this means one can have multiple traversals. For example, instead of amending the change to change which changed files to commit, they can just go to the point in time where they didn't do the change yet and then commit the changes from there and change the selection of changes for their own traversal.

Deletion of traversals

The deletion of traversals is just a deletion of a record of selected changes. This means, users can delete a traversal while preserving the changes.

Can traversals have conflicts?

Yes. Fortunately, it is unlikely for the by-default recorded traversal because it imitates Git's linear history.

However, if the user wants to do some changes that requires conflict resolution when selecting which change to traverse, they will be able to by creating a shallow snapshot of the overall traversal and then do some conflict resolution there.

In this way, the user can avoid writing anything to the desired snapshot and use a duplicated copy and do some changes. Once conflicts are resolved, the user can delete the duplicated copy of the snapshot and put a new change which will be updated as the latest point of the traversal.

Integrating with ICP

Why ICP?

Incentivize contributors

contribTokens

Other solutions

Forges such as Forgejo and Gitea are going towards ActivityPub integration. This allows to take back the decentralisation of Git.