Early 2021 I started to work on fedeproxy, 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 I knew very little about the ActivityPub protocol, the Gitea codebase or its community. But I thought it would be years before all forges are able to communicate with each other using some kind of standard protocol and the past months confirmed this initial impression. So I decided to bootstrap the codebase of fedeproxy using the language that I’m most comfortable with, Python.
During the summer of 2021, while working on the fedeproxy python codebase, I got a better understanding of what is at stake when implementing ActivityPub. I also got a chance to better understand how the Gitea community is organized. The work I did 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. Since July 2021 I also became a co-administrator of the Chapril Gitea instance.
In August 2021, I started to doubt that pursuing the implementation of fedeproxy in python was the best option. There was no push back, on the contrary. A month later I decided to flip the switch and Pierre-Louis also decided to go in the same direction.
In retrospect it was a mistake to begin with a python codebase. But I did not know then what I 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, I decided to start with a Gitea fork which yields additional benefits:
- 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 scope of the fedeproxy project does not fit in Gitea. For this reason it will remain a fork which may be challenging when the code architecture changes. But it will sometime be beneficial. For instance 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. An example is the recently added private key generation.
I’m not aware of a software project that went this way and unexpected difficulties will arise. But I think it makes intuitive sense 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 allow issues across instances, fedeproxy will become redundant for this particular feature and the associated code can be removed. 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. Another example is the implementation of the ActivityPub protocol in fedeproxy: it will evolve at a different pace than the ActivityPub protocol in Gitea because the two projects do not have the same release cycle. But there is no reason to integrate the protocol in different ways and eventually fedeproxy will re-use whatever Gitea instead of have its own, slightly different, implementation.