<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[I've been carrying around an idea for a federated code forge for a while.]]></title><description><![CDATA[<p dir="auto">I've been carrying around an idea for a federated code forge for a while. Two things sharpened it recently: <a href="https://tangled.org/blog/forge/" target="_blank" rel="noopener noreferrer">Tangled's post on the federated code forge</a>, which builds a forge on the AT Protocol, and a <a href="https://hackers.pub/@turingappledev/01a15743-1f8c-70f5-a641-ea0576cb2fcf" target="_blank" rel="noopener noreferrer">Jujutsu workshop</a> (Korean) by <a href="https://boltless.me/" target="_blank" rel="noopener noreferrer">Seongmin Lee</a> (<a class="plugin-mentions-user plugin-mentions-a" href="/user/boltless.me%40bsky.brid.gy" aria-label="Profile: boltless.me@bsky.brid.gy">@<bdi>boltless.me@bsky.brid.gy</bdi></a>), who works at Tangled, held at <a class="plugin-mentions-user plugin-mentions-a" href="/user/turingappledev%40hackers.pub" aria-label="Profile: turingappledev@hackers.pub">@<bdi>turingappledev@hackers.pub</bdi></a>.</p>
<p dir="auto">My version would build on <a href="https://forgefed.org/" target="_blank" rel="noopener noreferrer">ForgeFed</a>, the #ActivityPub protocol for code forges (<a href="https://forgefed.org/spec/" target="_blank" rel="noopener noreferrer">spec</a>), 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:</p>
<ul>
<li>Git and <a href="https://www.jj-vcs.dev/" target="_blank" rel="noopener noreferrer">Jujutsu</a> (so-called <code>jj</code>) 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.</li>
<li>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 <code>forge.example/myrepo</code> instead of <code>forge.example/owner/myrepo</code>.</li>
<li>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.</li>
</ul>
<p dir="auto">Where this stands: I haven't read the whole #ForgeFed spec, Fedify doesn't ship the vocabulary yet (<a href="https://github.com/fedify-dev/fedify/issues/751" target="_blank" rel="noopener noreferrer">fedify-dev/fedify#751</a>), 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.</p>
<p dir="auto">#codeforge #fediverse #fedidev</p>
]]></description><link>https://forum.pierobosio.it/topic/ff3ea295-5f19-412b-95ff-c5de95e07a56/i-ve-been-carrying-around-an-idea-for-a-federated-code-forge-for-a-while.</link><generator>RSS for Node</generator><lastBuildDate>Wed, 11 Nov 2026 01:52:05 GMT</lastBuildDate><atom:link href="https://forum.pierobosio.it/topic/ff3ea295-5f19-412b-95ff-c5de95e07a56.rss" rel="self" type="application/rss+xml"/><pubDate>Sun, 08 Nov 2026 02:04:58 GMT</pubDate><ttl>60</ttl></channel></rss>