October 17, 2021
Early 2021 the fedeproxy project was created to build communication bridges between forges. It would allow to create a bug report on a project hosted on GitLab even when using Gitea. At that time community members knew very little about the ActivityPub protocol, the Gitea codebase or its community. But they knew it would be years before all forges are able to communicate with each other using some kind of standard protocol. So they decided to bootstrap the fedeproxy codebase using the language that they were most comfortable with: Python.
How the decision was made
During the summer of 2021, while working on the fedeproxy codebase, they got a better understanding of what is at stake when implementing ActivityPub. They also got a chance to better understand how the Gitea community is organized. The work that was done on a grant application to implement federation in Gitea was an opportunity for personal interactions with a few of the most active members of the Gitea project. In July 2021 they also became a co-administrators of the Chapril Gitea instance.
In August 2021, there were doubts that pursuing the implementation of fedeproxy in python was the best option and a rewrite in Go was proposed. There was no push back, on the contrary. A month later fedeproxy community members agreed, although Go is not their native programming language.
Where Gitea fits in
In retrospect it was a mistake to begin with a python codebase. But fedeproxy community members did not know then what they know now. It would be an even bigger mistake to keep going with the current codebase for the sole reason that it exists. It would deprive fedeproxy of the following benefits:
- An ActivityPub implementation that includes forgefed;
- Sharing code with the federation effort in Gitea;
- Developing the Gitea dump/restore file format into a standard
Instead of bootstrapping an entirely new codebase, it will be bootstrapped with a Gitea fork which already implements:
- Dump/restore feature;
- Migration feature which includes API interactions with a range of forges;
- Embryo of an upload feature;
- Mirroring infrastructure, although limited to git repositories;
- REST server;
- In memory representation of issues, pull requests etc.;
- Release process;
A large part of the Gitea codebase is irrelevant in the context of fedeproxy and the fedeproxy project, as a whole, does not fit into Gitea. It would be tempting to only cherry pick from Gitea in order to populate the initial fedeproxy codebase. But it would then be very difficult to track the evolution from Gitea and merge them back into the fedeproxy codebase. Taking on the entire codebase makes it easier, as long as the fedeproxy code is carefully crafted to minimize the risks of a conflict.
A concrete example of code that will be shared is the integration of go-fed should be almost identical in fedeproxy and Gitea. Whatever improvement is implemented in fedeproxy can be contributed to Gitea, and vice versa. Another example is the recently added private key generation.
There are well known examples of successful projects that are based on a codebase that has an independent lifecycle, such as Grsecurity, a set of patches on top of the Linux kernel. The methods and tools to manage such a project are different than what is common when creating a codebase from scratch, but they exist (see git rerere for an example).
Impact and way forward
It makes intuitive sense to start in this way because fedeproxy’s ultimate goal is to disappear when all forges are able to communicate with each other. For instance, when Gitea is able to gracefully federate issues across instances, fedeproxy will become redundant for this particular feature and the associated code can be removed from fedeproxy. The same will be true for GitLab when it natively allows issues to be federated between instances using a standard protocol and vocabulary. And when all forges use the same standard to federate issues, the fedeproxy code bridging issues can be removed entirely.