The Fediverse hasn’t really made much obvious progress in 2025. Monthly active users have steadily eroded during the year. The billionaire-owned centralised networks have consolidated their control over social networking generally. If the goal is to replace Twitter or Facebook, really things are more bleak than ever before. Many governments around the world are vocally acknowledging the damage done by big social media platforms, but there has been practically no effort to use alternatives instead. If Trump’s blatant conscription of these channels for his own vile purposes can’t convince Europe to stop validating them with their presence, what else possibly could? And why would any smaller players risk taking a stand? No, at this point I couldn’t in good conscience tell my friends that the Fediverse is the best way to connect with me.
Despite that, development of the Fediverse continues unabated, and still has plenty of untapped potential. It’s just that the immediate opportunities now don’t much resemble Twitter or Facebook. Instead, I want to highlight a project that’s had me excited for a while now: Forgefed.
In some ways, this is a pretty disappointing thing to be talking about. It’s a retreat to the nerd market. At first, projects like Friendica started with the intention of being accessible to average users. But the nascent Fediverse quickly descended into a hobby purely for technically-minded open source geeks. For a brief moment the Twitter migration looked like it could change that. But the new arrivals quickly learned that open source culture dominated, including its more toxic habits. So large portions ended up back on Twitter, while the minority more committed to breaking the billionaire stranglehold moved to Bluesky. The Fediverse germinated in the open source movement, but that same soil killed all its attempts to reach any further. And now my greatest hopes are invested in a replacement for github, something only a tiny fraction of people have ever heard of.
Nevertheless. Forgefed is leveraging ActivityPub to deliver something genuinely new and compelling. I think it’s the right model, that could be imitated in other areas. So this is a critical pathfinder.
Jira
A large portion of my current professional work involves delivering software for one particular customer. That customer uses Jira as their issue tracking software. That’s handy, because my company also uses Jira internally. Perhaps this is not such a remarkable coincidence. Atlassian dominates this market.
But there’s a problem. This customer has their own internal Jira instance for reporting problems, while our Jira instance is entirely separate. Frequently it’s not clear if an issue should be solved by our team or by one of our customer’s other suppliers (each of which presumably has their own separate Jira instance). So while at a high level we describe tickets bouncing back and forth across company boundaries, in practice tickets are duplicated. Each accumulates notes explaining that such and such an action was taken, revealing a dependency on another company’s ticket. They then sit in “waiting for information” state.
But the information that is accumulated is essential for engineers from all sides. It’s not enough for us to add information to our Jira ticket, we must also copy that information to the Jira ticket on the other side. From there, it must flow to further Jira systems. How does this synchronisation happen?
I honestly don’t know. It does appear to be done automatically. But the implementation is dreadful, with different fields being synced inconsistently. Comments on our tickets do not propagate to our customers’ tickets. Attached files sometimes do, in some directions but not others. Most ridiculously and frustratingly, the only way we can have a dialogue is for our comments to be prepended to an “Information” field, while replies are prepended to a “Feedback” field. We have to manually sign and date each paragraph so that it’s at least feasible for a human to make sense of it all. Inevitably, tickets often get deadlocked, two teams each believing the other is responsible. And frequently the whole fragile system falls apart entirely. Given the skills of the engineers using this system, it’s darkly hilarious that we’re relying on such a terrible solution for tracking our work.
Does Atlassian provide a sensible system for synchronising tickets across instances? Maybe? Probably? I suppose they’re working on it? Or, more likely, they are trying to force everyone to migrate to their cloud, so that the process can be brought under Atlassian’s control. I guess that some companies’ desire for independence, contradicting Atlassian’s priorities, is a big part of why this whole system works so poorly.
Open Source
It could be worse though. Consider the world of open source projects.
These days I almost never submit a bug report. It’s vanishingly unlikely that it would result in a positive outcome. The most usual result is that some volunteer decides that my bug is caused by some completely different piece of software, and closes my ticket as invalid. Quite likely this comes with a snide remark about my lack of understanding or my inability to read the FAQ.
I would be angry about this, but that’s the same behaviour I exhibit in my professional life. As the resident expert on my own software, I can quickly spot context that was missed by the original reporter, that would suggest another team could more usefully investigate. Of course, that team frequently concludes that after careful examination, my software was at fault after all. With that context I will gladly make some changes. But swatting a ticket back over the fence is an essential part of my work.
It’s just that unlike the messy Jira synchronisation I fight with every day, open source software has no issue synchronisation or reassignment mechanism at all. Those maintainers cannot reasonably be expected to open a whole new ticket on a distantly-related bug tracker on my behalf. And as a bug reporter I can’t be expected to do that either. Opening one ticket is a high enough barrier as it is, and the patronising comments certainly discourage me from pursuing the issue further.
Protocol
Forgefed is a specialisation of ActivityPub for “forge” sites like github and sourceforge. Github in particular has become dominant enough that the corresponding workflows are now an expected part of every developer’s skillset. Many younger developers now find the terms “git” and “github” confusing, and use them interchangeably. The features of github are standardised and genericised. The time is ripe for formally specifying these. That’s what Forgefed does.
Github made it trivially easy to create your own fork, but then contribute changes from your fork back to main. In effect this became the core workflow: the “pull request”. But with Github, the fork must reside on the same system as the mainline. With Forgefed this is no longer necessary. The fork can run on a different server than the original. More importantly, the two can run entirely different software stacks. They communicate over a formally-specified protocol.
Tickets
Pull requests are the most obvious and natural feature for Forgefed to concentrate on. But the interesting part of this for me is synchronisation of tickets. That’s a feature I would expect to arrive some time after the proof of concept feature, pull requests, is well-established.
The special problem with tickets is that every organisation and every project develops their own collection of specialised fields, that are essential for assigning, validating, and prioritising each bug report. The metadata associated with a bug report is far more sprawling and complex than that associated with a pull request. In order to be really useful, forge software needs to support organisations managing this data, and the synchronisation protocol needs to support translating this metadata between incompatible instances.
JSON-LD
It so happens this is the problem ActivityPub was designed to solve. ActivityPub is based on JSON-LD, which in turn is a representation of RDF. The protocol was developed with the explicit intent that every organisation should be able to develop its own vocabulary for describing “objects”, and that vocabulary would be passed unmodified even among systems that have no idea how to interpret that data. Every field in ActivityPub is labelled not just with a string, but with an entire URI. That URI is under the control of a domain, which is under the control of an organisation. And so different organisations can describe the same object with different fields without ever interfering with each other. Meanwhile, common structures such as comment threads can be shared easily.
If I worked at Atlassian, and my job was to build a protocol that would allow companies like my own to communicate with each other effectively, JSON-LD would almost certainly be the foundation of my solution. Perhaps I would not ever consider ActivityPub. But here we are, ActivityPub does seem to have emerged as an early contender. And in the end I don’t expect Atlassian to attempt to compete with that, because Atlassian’s incentives don’t lie with an open protocol in the first place.
Opportunity
For me, Forgefed is largely associated with the Forgejo project. This is unfortunate: this cannot simply be a sideline of one particular opinionated group of developers. Nevertheless, Codeberg has emerged as an important rallying-point for those distressed by Microsoft’s dubious stewardship of Github. Codeberg is committed to, and largely funding, the Forgefed effort. The network effects are likely to be considerable here. Github only exists because Git itself became so entrenched in developers’ habits, and Git was originally a vanity project of Linus Torvalds for the particular use of maintaining the Linux kernel. I think similar dynamics could drive wide adoption of Codeberg and Forgejo. And if they fulfill the promises that drove their success, that will come with an open protocol that other projects can utilise. If the momentum is strong enough, perhaps even Atlassian may embrace the standard.
I started this year with a blog post calling for more use of extensible metadata within the Fediverse. Forgefed is nerdy, but it’s the clearest example I’ve yet seen of how that extensibility could be utilised in practice. More than that, this is not just “XYZ, but with ActivityPub”. This is the first serious attempt to solve a problem that we have endured for decades – a problem that is also costing big players serious money. There’s a genuine opportunity to make something new and worthwhile, even lucrative, and ActivityPub is the foundation of that effort. That’s what makes this the most exciting development in ActivityPub in 2026.