Yes on the What and Hown. No on the Where.
It is.
Here is an example based on what will happen:
- fedeproxy merges the add user settings key/value DB table pull request in its codebase
- fedeproxy implements the ActivityPub’s endpoint that returns information about an actor, including its public key (e.g. /users/loic), based on the code from the “add user settings key/value DB table” pull request
- a pull request is opened in Gitea to propose the code implementing this new endpoint
- the pull request is merged into Gitea
- fedeproxy merges back the Gitea codebase and there no longer is a difference between Gitea and fedeproxy on this particular feature.
This is what I meant by “disolution”. It would of course be much, much less work if the endpoint could be implemented directly in Gitea instead. But the lifecycle of fedeproxy and Gitea are different and it would block any progress on fedeproxy during months while waiting on Gitea.
There are part of fedeproxy that do not make sense for Gitea to include, such as acting as a reverse proxy for the ActivityPub protocol on behalf of a GitLab instance. This will not be “disolved”.
It is very close to what I have in mind, with the following difference:
- Do not strip the uneeded code, just ignore it
- Merge the Gitea codebase on a weekly basis in fedeproxy
- Build fedeproxy specific code in a way that minimizes the likelyhood of a merged conflict