What we currently have is:
- ForgeFed: A protocol specification that standarizes ActivityPub message formats & interaction for forge2forge git sync.
ForgeFed focuses on a subset of the functionality forges provide (e.g. leaves out Issue Management). FedeProxy aims to expand forge interoperability further from there.
So what may be deliverables of FedeProxy project are:
-
FedeProxy protocol: Seamlessly expands and/or extends on what ForgeFed provides. Species a standard way of federated communication that can itself be further extended over time.
-
FedeProxy platform: A full-blown ActivityPub-enabled server, from which people spin up FedeProxy instances. Importantly this platform has a ports & adapters architecture, and a plugin mechanism to add these.
-
Application-specific extensions: These may be anything, but it starts with e.g. OAuth or Webhook apps that make a specific forge software communicate to a FedeProxy instance.
Now let’s say I have a Gitea server and a Gitlab server and want to make them interoperate together. Then:
- I could use an existing FP instance hosted by someone else, that has both Gitea and Gitlab connector plugins.
- I could spin up my on FP instance with both plugins
- Maybe the Gitlab is not under my control, but already exposed on fedi by a FP instance to which I don’t have access. I could spin up my own FP instance with only a Gitea connector and ask to configure my instance on the Gitlab endpoint.
Note that I talk about Gitea / Gitlab i.e. on forge level, but the configuration has a granularity to the individual repositories where different configs (e.g. auth/authz) can be specified.
Now this is all great: forge2forge interop… been there, done that.
What happens if a forge implements native FedeProxy protocol support? Well, they may not need to spin up their own FP instance. They directly connect to remote instances and have better integration of FedeProxy config etc. in the UI.
Where does extra power in this set up come from? It opens many different scenario’s and use cases that go well beyond forge synchronisation:
- A portal website that aggregates activity metrics on a broad range of projects, where people filter and search based on their interests.
- A documentation website (e.g. CMS or Wiki) that receives as input filtered project-related information that are relevant to Technical Writers.
- A CI/CD service that does cross-forge complex multi-project builds, and reports back to each one of them.
- A Trello board, Mattermost workspace, Basecamp project, Matrix chatroom, etc. that processes project activity in any way it wants.
None of these extended use cases are part of the FedeProxy project itself, but they are enabled by it.