Hi people!
I’m here to discuss the possibility of implementing ForgeFed federation in Gitea. I’m aware this has been discussed in the past, here and in some githu8 issues in the Gitea repo, but the picture is clearer now and I have practical details that I think we can work with.
I’m working on ForgeFed, which is a protocol for federation of project collaboration platforms. It’s based on ActivityPub.
The only way to develop a protocol and a vocabulary is by learning lessons from implementing federation in real forges. So far I’ve been working on a forge that I wrote myself, and I think I’ve figured out enough detail to start implementing on a real usable forge with many deployments. With the basic pieces in place, Gitea can be used for refining and finalizing the protocol, and we’ll have a usable federated forge that everyone can use.
I haven’t started writing a spec draft, but once I do, I’ll announce it. Either way, most of the detail is ActivityPub, which already has a spec and many implementations.
Basically, I’m dividing the work on federation a forge (Gitea or any other) into 5 pieces:
- Storing and displaying content sent by users from other servers
- Parsing messages received from other servers
- Delivering content to other servers; authorizing and caching content from other servers
- Allowing local users to create objects for processing by other servers, such as creating a merge request or an issue on a repo hosted on another server
- Accepting and delivering remote requests for resource modification, based on repo permissions
Item 3 can mostly be handled using a job queue and an HTTP Signature library, and we’re also working on a federation server component that abstracts away these details, handling these things automatically, including managing follower lists and hosting locally authored ActivityPub objects. So let’s say item 3 is covered: It’s somewhat standard, and we’re already working on a ready solution for it.
Item 4 is what allows Gitea not just to accept federated objects, but also to produce them. This requires mostly UI changes.
Item 5 involves authorization tokens, I’m still working on this part. Once the details of it are clear, it can be implemented in forges. For now, it can wait.
That leaves us with items 1, 2 and 4. I’d like to suggest the following basic roadmap for implementing federation. And I’m happy for any feedback on it 
Step 1: Implement item 1 above, which is storing and displaying remote content. In practice I suggest the following: Allow, in DB and UI, that the author of the following objects can be either a local user, or a remote user from another server:
- Issue
- Issue comment
- Merge request
- Merge request comment
This requires DB tables and UI updates. In practice, for now there will be nothing authored by remote users, so the UI of Gitea will appear exactly the same, but it will be ready for handling federated issues, comments and merge requests.
Step 2: Implement items 2 and 3, by using an ActivityPub library for parsing the ActivityPub JSON objects, and either an HTTP Signature library or the more thorough federation server I mentioned above, which will cover a lot more.
With step 2 done, a Gitea server will be capable of accepting issues, comments and merge requests from other servers. The most simple case is comments. Gitea still won’t be able to produce such federated objects, but we’ll be able to test against forges that already can (such as the one I’m working on, which isn’t nearly as usable as Gitea but is more than enough for testing federation).
Step 3, implement item 4 above, which means using an ActivityPub library to encode ActivityPub JSON objects. There are also new UI pages to make, through which users will submit the content, and an asynchronous delivery system, but delivery can be handled by the federation component I mentioned, or by any existing job queue system (iirc people often use Redis for this). So it’s mostly UI work, and producing ActivityPub objects using a library.
Step 4, implement authorization tokens and activities that involve them.
So, the first self-contained step is basically, conceptually, to have a “users from other servers” database table, where each user is a URI from some other forge website, and then allow the authors of issues, comments and merge requests to be such users-from-other-servers.
It would be great to use Gitea to prototype and refine the protocol and vocabulary, and not just wait until the protocol is finalized using other forges. The only other forge I can think of that I see is use very often is GitLab CE, but GitLab seems much more complicated to me, making Gitea the easier more natural choice for implementing and prototyping federation.
What do you think?
Ask me anything