I've been carrying around an idea for a federated code forge for a while. Two things sharpened it recently: Tangled's post on the federated code forge, which builds a forge on the AT Protocol, and a Jujutsu workshop (Korean) by Seongmin Lee (@boltless.me), who works at Tangled, held at
@turingappledev@hackers.pub.
My version would build on ForgeFed, the
#ActivityPub protocol for code forges (spec), so that repositories, issues and merge requests federate the way posts already do. The idea is early enough that I haven't even come up with a codename. What I want from it, roughly:
Git and Jujutsu (so-called jj) as equal clients. Not Git hosting with Jujutsu support bolted on, but a forge that understands both, so what Jujutsu is actually good at, stacked changes, becomes a first-class unit of review instead of a pile of separate pull requests.No owner layer. Since the point is federation, one instance represents one person or one organization, permissions are managed per server, and a repository lives at forge.example/myrepo instead of forge.example/owner/myrepo.A migration path off GitHub that keeps the history. Importing the code is easy; importing the issues, pull requests and discussions with their original authors attached is the part that matters. I'd keep a placeholder for each GitHub account and let whoever owns that account prove it, after which the instance swaps in their fediverse actor, so attribution carries over. How to express that claim in ActivityPub is the part I haven't figured out. It may need a new FEP.
Where this stands: I haven't read the whole
#ForgeFed spec, Fedify doesn't ship the vocabulary yet (fedify-dev/fedify#751), and I have too much else going on to start soon. If you've run a forge or implemented ForgeFed, I'd like to hear whether any of this makes sense.
#codeforge #fediverse #fedidev
