### Introduction Hello there :) I am Christoph, I am part of the ForgeFed working group which is developing a specification for federating "Software Development Forges" using ActivityPub (AP). While the spec is still in the works I would already like to play a little bit around with the software that could benefit from this, namely GitLab, Gitea, and Gogs. Mainly to get a better feeling what is required to be in the spec. :) Because I am not very familiar with Go yet, I decided to start with GitLab. I am opening this issue to present the current state of my mind regarding this and to open the discussion with the GitLab community so I don't implement a thing that nobody likes. :) So far I already have a small plan of action. It involves this steps regarding the user and project core entities: * expose them as JSON-LD / ActivityStreams / AP objects (including project issues) * implement (remote) browsing? (this is a challenging UI task to me) * add outboxes to them * add inboxes * make entities followable (implement the side-effects of the `Follow` activity) * make inbox browsable for the owner? * deliver new events to followers through AP means * allow adding new comments to existing issues via AP * open new issues via AP There is a also a alternate plan, parallel to the tasks above, related to #14116: * forking of remote project repositories * creating MRs for remote projects * sending MRs to remote projects [I already have tinkered a little bit around with exposing the objects](https://gitlab.com/criztovyl/gitlab-ce/commit/39d6a2cd331e67ae3b2e7e242c3a82501ca1f54a), by adding a new `jsonld` format to the corresponding controllers. The JSON is built with [JBuilder](https://github.com/rails/jbuilder). Right now I am thinking about where to put the (remote) browsing of objects. Initially I imagined it as a third drop-down in the top bar, after "Projects" and "Groups", like "Projects", "Groups", "Federation", "Activity", ..., but UI/UX wise that might not be the wisest choice. ^^ Nothing of this is set in stone yet, I am open to suggestions and discussions. :) Thanks for reading. Below some more, but still incomplete, information that the Feature Proposal template suggests to provide. --- ### Problem to solve Federated GitLab (#14116, #21582). ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> Users on GitLab.com or that self-host GitLab but want to interact on other GitLabs or even other forges like Gitea/Gogs. ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> See Introduction. :) ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Implement the ForgeFed Spec in GitLab. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> some bullet points (WIP): * ActivityPub Inboxes will need to allow unauthenticated POSTs from the open internet. This is how ActivityPub works, but might be a challenge in regard to Spam. * Speaking utopian, Users and Identities should be separated. Local users would have both, remote users only Identities. ([Read more.](https://talk.feneas.org/t/criztovyls-forgefed-web-log-tfo-edition/59/10)) * ...? ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> N/A ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> N/A ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> * I can follow my GitLab user via ActivityPub * Merge Requests can be created locally for branches of remote projects / repositories * Merge Requests can be created remotely for branches of remote projects / repositories * ...? (WIP) ### Links / references * #14116 * #21582 * [ForgeFed category in the forum of the Federated Network Association (Feneas)](https://talk.feneas.org/c/forgefed) (:wave: @jaywink) * [A topic of mine regarding my work on ForgeFed](https://talk.feneas.org/t/criztovyls-forgefed-web-log-tfo-edition/59/35) *Edit Sep 14: Fixed links of moved issued, extended description*