Against Federated Forges

Posted: 2023-01-31 #rant #software
3 minute read.

https://ak.kyaruc.moe/notice/ARkFS5pDpJ2riPc1SK

Introduction

A couple of weeks ago, I got into a “heated” debate over the usage of ActivityPub in the context of a “federated forge” with forge being a hosted git platform, such as gitlab, gitea and whatnot. While that wasnt the original topic of the thread (not by a longshot) I wanted to pick the couple of posts which the idea was thrown around and give my opinion on the topic.

Federated forges is a really stupid idea.

Problems

Now before I get into my whole argument, lets lay down some of the contexutal groundwork. The original topic of the thread was a commentary on the corporataization of the fedi, eventually leading into a “what can we integrate ActivityPub with” hypothetical. Interestingly enough the topic of gitea was brought up, but with no precise example of where it could be useful.

You see, all this stuff could be integrated with ActivityPub.

For example, Gitea is integrating with ActivityPub. So that’s helpful for bug tracking.

https://social.gitea.io/@gitea/107576791626052697

Anyway, all of this stuff needs iterating.

What does ActivityPub aim to solve? The most cited example is “vendor lock-in”. the unfortunate consequence of this assertion is that everything the vcs does falls under that umbrella. Including the platform which it is hosted on.

Why it doesn’t work

When we consider git in a vaccuum, it is simply just a version control system. It deals only in that realm. Natrally many projects may want an assortment of the following:

• Issues (bug tracking)
• Pull Requests (code submission)
• Wiki (documentation)
• Workflows (ci/cd)
• Discussions (community/developer interaction)

These are tools that help, but they all require that you have a form of auth. Some people have combined all of these services into one platform, like git{hub,lab,tea} adding some convenience, but at the cost of being totally reliant on these platforms. Naturally this leads to problems of requiring an account on github, for example, to contribute to x project¹.

Now why federation is a stupid idea: fist lets consider what are some of the most “transactions” in a typical project. In the case of a new commit/revision, you’d have to proxy that diff info, potentially hundreds of megabytes depending on the diff size, to many separate servers unrelated to your own. The same for each, discussions, posts, signatures, and code would all have to be transmitted to other peers. Creating a network and processing overhead.

While this isn’t necessarily a bad thing, it can lead to a lot of undesirable situations due to the fact that there is no deliberate control of what can be sent/received.

If you don’t want to deal with vendor lock-in, then maybe just make your source control site anonymously accessible for non-dev tasks. Its actually quite easy, with the added bonus that you don’t have to maintain code to deal with an already large protocol.

Have a comment or question? Shoot an email to ~theorytoe/public-inbox@lists.sr.ht, my public inbox.