Thanks for sharing! Here is an English translation for the archival.
Prototypefund application Gitea
project title
Gitea in Fediverse
Project description
Gitea is a software development application that provides a lightweight alternative to source code hosts like GitHub and Gitlab because it is very easy to self-host. The Gitea project is one of the top 500 projects on GitHub and is extremely popular with over 100 million Docker pulls. It is suitable for teams of various sizes for source code management. Users can create their own Git repositories and manage them via a built-in ticket system.
A challenge for the future is the networking of individual instances, which will be addressed in this project.
What social challenge do you want to address with this project?
Existing proprietary providers such as GitHub and Bitbucket usually host their service in their data centers and offer individual users little opportunity to check what happens to their data there. One way out of this is to migrate one’s own data to a self-hosted Gitea instance. In this case, however, the user loses the “community factor” of the platform, through which they can also view projects of other users and participate in them, for example, by making code changes. Due to centralization, in extreme cases a user would have to register anew for each project in order to interact with it.
To compensate for this disadvantage, Gitea instances should be given the opportunity to be networked with each other. For this purpose, Gitea should become part of the Fediverse and exchange data with other source code forges via standardized protocols. This would allow a user to find and use projects of other users with their local Gitea instance. Fediverse is designed as a decentralized network and thus does not lead to the vendor lock-in problem described at the beginning.
How do you want to implement your project technically?
For the technical implementation of the network, a data protocol based on ActivityPub (ActivityPub) has to be implemented. For this purpose, we will collaborate with the ForgeFed project (https://forgefed.peers.community/), which has created a first draft of such an extension for ActivityPub. The draft defines different entities for the networking of source code forges.
The following points have to be implemented:
- To be able to use the protocol, the internal Gitea structures have to be adapted to the entities used in the protocol or a mapping between them has to be created.
- For all actors (users, repositories, tickets), incoming and outgoing interfaces (inbox, outbox) must be created, to which foreign instances can connect. For both, possibilities for intermediate storage of data in the database must be created.
- Sending activities (storing in the outbox of an actor) must be connected to the corresponding functions in Gitea.
- Receiving activities (reading from an actor’s inbox) must trigger corresponding actions in Gitea (e.g. creating a ticket or comment).
What similar approaches already exist and what will your project do differently or better?
To share source code between instances, you can use Git’s push and pull functions, which allow you to mirror a foreign repository via script. The mirroring usually only applies to the source code and does not work bidirectionally.
With Vervis (https://dev.angeley.es/s/fr33domlover/r/vervis/) a reference implementation of the ForgeFed protocol exists, which serves as a demo platform.
Who is the target audience and how should your project reach them?
Anyone already using Gitea can benefit from the extension to network with other instances. Once a new instance joins the Fediverse, it can access other users’ content and vice versa.
Private networks within an organization can also be formed in this way, allowing different sites or divisions to join together.
Briefly outline key milestones to be implemented during the grant period.
- Evaluation of the forgefed protocol and how it can be used in Gitea
- Implementing the protocol for the actors user, repository and ticket
- Testing with Vervis