FR: Federation via ActivityPub/ForgeFed

[erlend-sh]

https://forgefed.org/

imagine you could host your Git repos anywhere you want, perhaps even your own personal website, but still be able to open issues and submit pull requests against other people's repos hosted elsewhere, without having to create accounts on those other websites!

GitLab has been evaluating this feature for a very long time, recently culminating in actual development on a proof of concept by @oelmekki

https://gitlab.com/gitlab-org/gitlab-foss/-/issues/4013
https://gitlab.com/gitlab-org/gitlab/-/issues/30672
https://gitlab.com/gitlab-org/gitlab/-/issues/21582
https://gitlab.com/groups/gitlab-org/-/epics/260
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/127023

edit: Summarized epic for federated merge requests:
https://gitlab.com/groups/gitlab-org/-/epics/11247

It’s a major undertaking that needs to be approached very piecemeal, but it’s also a very impactful differentiator that GitHub is unlikely to ever support because it compromises their most.

[oelmekki]

Someone summoned me? ^^ Hello 👋

Just worth noting that we're not starting right ahead with ForgeFed, we first implement pure ActivityPub for social interactions, in order to build up the infrastructure we'll later need for more complicated tasks like what ForgeFed is about (federated issues and merge requests). Gitlab has been very receptive to the idea and they allocated time to one of their developers to help me work on it, so the chances of this happening are high. :)

By the way, this is the first time I hear about jj, it looks awesome!

[martinvonz]

I haven't yet understood what ForgeFed or this FR is about. What would it mean for jj in practical terms? Would it mean that we would have jj forgefed send-mr and related commands?

By the way, will ForgeFed support stacked PRs better than GitHub does? Specifically, GitHub doesn't let you send a PR based on another PR (aka branch) that's not in the destination repo. It looks like ForgeFed's protocol lets you send a series of patches in a PR/MR, but I couldn't figure out of those patches are regular (git-flavored) patches or if they refer to commit ids.

Also see #485.

[oelmekki]

I haven't yet understood what ForgeFed or this FR is about.

The idea of ForgeFed is to be the fediverse of code : an extension of ActivityPub to allow interoperability of projects management tools (think: opening an issue or merge request from your favorite forge to a project hosted on an other forge). In the context of Gitlab, we're interested in it to allow collaboration between all instances of Gitlab, both gitlab.com and all the on-premise ones, without having to create an account on each one. And building that on top of ActivityPub allows for such collaboration with all forges implementing it. As for what it means for jj, I leave it for @erlend-sh to answer, I'm just a guest on this issue. :)

By the way, will ForgeFed support stacked PRs better than GitHub does?

I don't speak for ForgeFed nor even Gitlab (I'm just a contributor to Gitlab) and we're far from starting implementing this part, but this is a good time to let me know about those kind of features you would want, so that we can plan them directly from the design phase, if they fit with the rest (no promise, obviously). I make a note with your comment and the linked issue.

[erlend-sh]

opening an issue or merge request from your favorite forge to a project hosted on an other forge

That’s the essence of what I have in mind.

I’m way out of my depth here as someone who exclusively submits .md PRs via the GitHub web interface, but seeing as jj has git interop it seems remotely conceivable that it could piggyback on git-based federation in order for a jj repo to send PRs to a git repo (e.g. on GitLab).

[necauqua]

seeing as jj has git interop

I mean, git and git.. hub are different things. Git is the version control system, that jj (kind of) builds on top of, the interop you've mentioned, and as far as git interop goes jj works perfectly with git remotes, which include github, gitlab and any other git server.

The pull requests are not part of git spec, and for jj to send PRs to something it has to work with that something.

I'm sorry I had to let the correction out of myself :) The phrase of yours I quoted didn't make too much sense, sorry again

Now, this thing actually does seem like the closest thing to being an open spec for PRs (and other "forge", as they call it, things, like reviews/issues/etc), so supporting it seems cool (as opposed to individually supporting e.g. GitHub PRs, which does not seem cool, but is a necessary evil it feels like), especially if it takes off, with at least gitlab potentially implementing it.

[oelmekki]

Now, this thing actually does seem like the closest thing to being an open spec for PRs (and other "forge", as they call it, things, like reviews/issues/etc), so supporting it seems cool (as opposed to individually supporting e.g. GitHub PRs, which does not seem cool, but is a necessary evil it feels like), especially if it takes off, with at least gitlab potentially implementing it.

I don't think it would help, sadly. ActivityPub is a client to server and a server to server protocol, similar to SMTP : the client authenticate with the server where they are registered to in order to send their messages, and then servers communicate with each others. And as SMTP, one major issue is spam. Fediverse apps like Mastodon and Lemmy solve that by having armies of volunteer moderators, but it's not something we want on forges. Which means we can't allow just anyone anonymously posting on issues, or worse, anonymously posting code through merge requests (can't even imagine where this would go, with all the talks about hardening supply chains through laws). There will probably be something like the whitelisting of instances allowed write access with the idea that each instance deal with their users if they behave maliciously- and thus, local running VCS won't be able to create issues or pull requests without going through a forge. Although again, this is the very beginning, maybe someone will figure a way to be more open. 🤷

[necauqua]

Well I meant more that there's a single API for you to log in with and submit PRs to any instance that conforms to the spec, so the same code and command in jj would allow you to do that with GitLab or with other instance or in some bright future GitHub will implement it too

[oelmekki]

I certainly would love to see that happening. ForgeFed touches the subject of client to server interactions, but they mention immediately it's not a priority, and that section is clearly underspecified.

Even in the existing Fediverse, apps like Mastodon, Lemmy, Kbin, Peertube, etc all have their own custom API to allow client to server communication : basically, they use ActivityPub for server to server communication, then they provide their own REST API for client to server. This is a bit sad given ActivityPub actually specifies a client to server protocol too, and not implementing it prevents having generic clients to use the various server apps. I think the reason for it is that their feature set expands beyond what ActivityPub provides and they don't want their API to be limited by it.

In any case, even if we end up implementing the client to server part of the specs and expand what ForgeFed drafted about it, this will only come after server to server communication will be up and running.

[necauqua]

Oh I see, yeah that's sad, I kind of jumbled it up in my head with matrix and nostr a little, didn't realise mastodon has custom REST, eh

[erlend-sh]

Thanks to kik there’s now a neatly summarized epic detailing the path towards ActivityPub-powered merge requests:

https://gitlab.com/groups/gitlab-org/-/epics/11247

The very first step of “ActivityPub to subscribe to project releases” is really valuable, as it makes it a lot easier for devs to do automatic fedi-announcements as part of their regular release workflow.

edit: this is clearly a feature many people are excited about:
https://writing.exchange/@erlend/110949168258462158