ForgeFed: an ActivityPub federation protocol for software forges

A protocol document, not a running forge

ForgeFed is described as an ActivityPub-based federation protocol for software forges, and the first thing to understand is what that means for the repository. There is no server here, no database, no web application and no client. What the project contains is the specification and the things needed to publish it: the source texts of the spec, the structured data files that go with it, the material for the website and the script that builds that website. That shape has consequences for how you evaluate the project. You cannot install it, and there is nothing to benchmark. What you can do is read a protocol that describes how forges should talk to each other, check whether it covers the cases you care about, and contribute text to it. The project site is forgefed.org, and the README also points to a forum and a chat room for discussion.

Bikeshed for the spec, JSON-LD contexts for the data

The primary language of the repository is listed as Bikeshed, and the reason is visible in the top level: there is a spec.bs file, a config.toml, and directories named spec, rdf, content, doc, templates and static, plus a build.sh and a deploy.sh. Bikeshed is a tool that turns a specification written in a prose-plus-markup format into a rendered document, which is why the language statistic looks the way it does. The structured side lives alongside it, with JSON-LD context files in the rdf directory, and a context.jsonld at the root. JSON-LD is how a protocol that rides on ActivityPub describes the shape of its objects, and a forge protocol that federates issues, commits and pull requests needs exactly that kind of vocabulary. The website itself is generated by a script from the Markdown files in the repository, and the README points at build.sh for the details. A .woodpecker.yml file at the root indicates the build is checked by CI rather than by hand.

Two reviews and a two-week cooldown for any spec change

The contribution rules are the most concrete thing in the README, and they explain a lot about how the project works. Nothing is pushed to the main branch directly; the project always opens a pull request. A pull request that changes the content of the specification needs at least two reviews, and then it waits for a cooldown period of two weeks during which more people can provide feedback, raise challenges and conflicts, and improve the proposed change. The project asks people who want to participate continuously in shaping the specification to go over the open pull requests once a week or so, so that they can state their needs and ideas before changes are merged. Read that as a design choice rather than bureaucracy. A federation protocol is a contract between independently run servers, so a clause that merges quickly and is regretted later is expensive in a way that a bug in an application is not. The cost is obvious too: a two-week cooldown means a change you care about takes at least a fortnight to land.

The issue tracker is deliberately narrow

The project reserves its issue tracker for practical, actionable work items, and asks that people who want to talk first write to the forum or the chat instead, opening an issue later if one is needed. The stated reason is to keep a manageable working environment. The two channels are the forum, hosted on an ActivityPub social hub, and a Matrix chat room on libera.chat, and the README invites people to open an issue for missing details, unclear text, improvement suggestions or feature requests. There is also a resources file, resources.md, that lists which team members have access to which project resources, and the project says outright that openness and transparency matter to it. That file is worth reading before you contribute, because it tells you who can merge, who can publish and who holds the credentials, which is the kind of detail that tells you how a project is actually run.

The project federates its own repository across forges

ForgeFed is mirrored on Notabug, on Pagure and on GitHub, and the README also carries a Codeberg badge. There is a mild irony in a federation protocol for forges keeping its own history on several forges at once, and it doubles as a demonstration of the practice the spec describes. A mirror is not the same thing as federation, and the difference is the point of interest in the protocol itself. A mirror copies history to another place, and the two copies then drift apart, each with its own issues and its own users. A federation protocol for forges instead lets separate forge instances resolve each other's objects, so a repository, an issue or an activity has one identity that several servers can serve. That is the difference in approach against simply running your own mirror, and it is also where the hard parts of the specification live.

CC0 for the text, a separate logo, and NLnet funding

Everything in the repository is made available under CC0 1.0 Universal, the public domain dedication. That is a deliberate choice for a specification: there is no attribution requirement, no share-alike obligation and no patent clause, so a forge implementation can take the text and implement it without the specification's own licence coming along, and a vendor can build a commercial product on top of it. Two details sit outside that grant. The ForgeFed logo was created by iko, credited in the same section as the licence statement. And the project is funded through the NGI Zero Entrust Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program, which is how a volunteer-run specification keeps a website, mirrors and travel to meetings funded.

Where the specification actually stands

Two observations about the state of the work. The first is that the repository publishes no releases, which is consistent with what it is: a spec that changes by pull request and is read on the website or in the source tree. If you want to cite a specific version of the protocol text, you cite a commit, not a tag. The second is the maintenance signal, which comes from the last push on 2026-05-03. That is inside the six month window, so the project is not dormant, but it is not a fast moving document either, and the cooldown rules partly explain why: a protocol that merges slowly by design will show quiet commit history between changes. The historical resources section adds context, since ForgeFed started on a mailing list and its old forum on talk.feneas.org survives through the Internet Archive. For anyone deciding whether to implement the protocol, the practical question is not whether the text is finished, but whether the object model in the spec matches the forges you already run.

Editorial conclusion

ForgeFed is worth reading if you run a forge, work on federated identity, or want to understand what a forge-level federation protocol has to specify. It is not a product you can deploy, since the repository holds no server implementation and publishes no releases. Before contributing, read resources.md to see who holds which project resources, plan for the two-review and two-week cooldown, and remember that the spec text is public domain under CC0 while the forge implementations that would speak it do not exist here.

Frequently asked questions

Official sources

1. forgefed/forgefed on GitHub
2. Issues
3. License: CC0-1.0
4. Project website
5. README