Fediverse Report -#147
This will be the last report for 2025, with a break over the holidays. It seems fitting to end the year with an effective end to the Threads <> fediverse integration. The interaction of Threads with the fediverse was a major part of the conversations on the fediverse in 2024, dominating the mind share and people’s understanding of what the risks to the network are. In 2025 those conversations died down, as it turned out that marginally few people actually made use of the connection. With the year at the close, it also means closing the chapter on the fediverse-Threads story for now (although it might be back some day, you never know).
Thank you so much for all your support and reading Connected Places this year, it’s been much appreciated, and I wish you all happy holidays!
-Laurens
The News
Threads’ integration with the fediverse is on maintenance mode, says head of Threads Connor Hayes in an interview by Alex Heath. Hayes said about the fediverse: ““It’s something that we’re supporting, it’s something that we’re maintaining, but it’s not the thing that we’re talking about that’s gonna help the app break out”. In October 2023, Mark Zuckerberg gave an interview with Alex Heath, who asked him about decentralisation and open protocols, with Zuckerberg saying he “always believed in this stuff“. With the fediverse integration for Threads now in maintenance mode, this must surely be a big blow for Zuckerberg’s belief in decentralised social networking.
Threads’ integration with the fediverse was never popular, especially from the side of Threads. In January 2025 the mastodon.social knew about 25k Threads accounts which had turned on federation. But while that number is already low considering the total number of Threads users, the interest in actually following an account on Mastodon from Threads was even lower: in January 2025, only 800 Threads users followed at least one account on mastodon.social. Threads deliberately made it difficult to follow fediverse accounts, and later updates deprioritised the fediverse feed even more. Regardless, it is not particularly hard to understand why a platform that now boasts about having 400M monthly active users is not putting in much effort to maintain a complex system that only a few thousand people at best make use of.
My take is that Meta and Threads have played the game well. They immediately capitalised on the moment in 2023 when decentralisation and Twitter-alternatives got large-scale attention, and knew how to say the right buzzwords to ride the wave. It got them in the right light for regulators, and gave them something tangible to point out to say ‘hey we’re doing interoperability now!’. The fediverse turned out to be highly vulnerable to such a strategy, a sitting duck for Big Tech companies to pluck some good PR from. That it turned the fediverse against itself, resulting in vicious and endless arguments about whether servers should block Threads, and whether Threads joining the fediverse validated the movement, was only a nice bonus. By slowly rolling out an implementation over the years Threads built their own positive-PR machine, every slight update worthy of a new article that put ‘Meta’ and ‘Interoperability’ in the headlines again. That nobody ever really used the integration between Threads and the fediverse never really seemed to matter, only the hypothetical future mattered. Nor did the press seem particularly interested in reporting on the fact that marginally few people seemed to be using the connection between the fediverse and Threads. Still, the company found itself a place at the table for protocol conversations about ActivityPub, which might pay dividend in the future if the need arises.
GGWP to Mark Zuckerberg and Adam Mosseri, for the skillful execution that helped Meta significantly, nestled themselves into the fediverse were it ever to become useful again, and taking some of the wind out of Bluesky’s sails as well as a bonus.
The WordPress ActivityPub integration has some interesting updates, with better moderation tooling support. You can now subscribe to shared blocklists, where the blocklist of your site will automatically sync with the source blocklist. This is an easy way to keep the moderation process automatic, provided you trust the source of the shared blocklist. The team also shared a sneak peek at a new upcoming feature, an ActivityPub reader. This is a client that turns your WordPress admin dashboard into a simple reader client, where you can see posts from the other fediverse account that your WordPress account follows. This feature is still in development, but the team is looking for feedback. It further cements the move of a WordPress site as a full-featured native fediverse server, that includes not only the technical backend part, but also the frontend of using the site as a fediverse platform.
This move also brings further competition to Ghost. WeDistribute’s Sean Tilley wrote an extensive overview of the current state of Ghost, saying it feels half-baked. One of the main standout features that Ghost has over WordPress is their reader client, but it seems like that it won’t stay that way for long.
Holos continues to be one of the most interesting projects on the fediverse from a technological perspective. The goal of Holos is to run an ActivityPub server on your phone. Because mobile devices are traditionally not particularly suitable for this (changing IP address, not always online), Holos adds a Relay service that mitigates these issues. The project posted an explainer of how it all works here. Holos also changes some long-standing dynamics in the fediverse: in this project, your data lives on your phone, which does mean owning and control over your data is more tangible than when you are dependent on your local friendly fediverse server admin. At the same time, it creates a new form of dependency, where the Relay operator manages your identity. This new type of implementing ActivityPub also introduces new unknowns regarding how account and data portability are handled. Still, experimentation is cool to see, and as mobile phones are the primary and often sole device for the majority of the population, it’s good to see fediverse projects that are even more directly mobile-first.
Speaking about mobile development: PeerTube has updated their app with a new creator mode. This allows people to manage their PeerTube channel, as well as uploading and editing new videos. During an crowdfunding earlier this year, which raised over 75k EUR, one of the specific goals of the campaign was to build a creator mode for the apps. Framasoft, the organisation behind PeerTube, promises even more features for the app, and says they are working on the ability for videos to play in the background, live streaming support, and a tablet version of the app. Publishing apps that allow for video streaming from a decentralised network on the app stores is quite a challenge however, as Framasoft found out: both Apple and Google are restrictive here, which forced PeerTube to limit the number of servers that could be accessed via the app.
Bonfire has completed their crowdfunding campaign, raising 32k EUR for the maintenance of the software. They describe putting maintenance of the software first as a matter of care. With the first implementation of the software, Bonfire Social, now ready and launched as a full version 1.0, there is now space to build and maintain the software for the long run. Bonfire does have a lot of plans (and unmet stretch goals) for growing the project, such as by adding support for groups. However, the first challenge is more practical: convince communities to start running and operating a Bonfire server. While some people are slowly testing out the software, nobody has committed yet to running a Bonfire server in production.
Mastodon says that they have plans to address a long-standing criticism within the community, namely that the mastodon.social server is too large in size compared to all other servers. Mastodon.social has 270k monthly active users, with virtually all other servers having 10k MAU or lower. The only exception behind pixelfed.social, with 60k MAU. This also ignores the two really bad places in the fediverse, Baraag and Pawoo, who are the second and third-biggest Mastodon servers with 40k and 18k MAU respectively. It is not yet known how Mastodon plans to handle this situation
Loops has added a For You feed, an algorithmic recommendation feed for the short-form video platform. While most of the microblogging side of the fediverse focuses on not having algorithmic feeds, short-form videos have different user expectations, leading to creator Daniel Supernault implementing such an algorithm. An infographic describing how the algorithm works is available here.
The Links
- This week’s fediverse software updates.
- Mastodon is looking for feedback on their upcoming Collections feature, their own interpretation on Bluesky’s Starter Packs.
- Mastodon has enabled their Wrapstodon feature, giving you a short overview of your account over the last year.
- The schedule for FOSDEM 2026’s Social Web Devroom is now live.
- Announcing Key Transparency for the Fediverse.
- The Social Web Foundation talks about implementing E2EE over ActivityPub.
- An exploration of using ActivityPub’s Client-to-Server part of the protocol (some context on C2S here).
- Fedify Developer Hong Minhee made a new logging library.
https://connectedplaces.online/reports/fediverse-report-147/
Fediverse Report – #148 – On Protocol Governance
The W3C has announced a new Social Web Working Group, starting January 15, 2026, to maintain and update the ActivityPub protoocol. The group will be chaired by Darius Kazemi, who created Hometown Mastodon fork and the Fediverse Schema Observatory. The aim of the Working Group is to release updates to ActivityPub, and its specifications such as Activity Streams and Activity Vocabulary. Most of the work on the protocol is scheduled to be done by Q3 2026, with the Working Group running until January 2028.
To understand why this matters, some context on how the W3C operates is necessary. The standards organisation distinguishes between Community Groups and Working Groups. Community Groups are open to anyone and serve as incubation spaces for ideas. Since 2018, the Social Web Incubator Community Group (SocialCG) has been the steward of ActivityPub. While Community Groups serve as a grass-roots place, they are very limited in publishing official documentations and formal updates to protocol standards. Working Groups, by contrast, are the bodies that can actually publish official W3C Recommendations, meaning formal standards. Participation in Working Groups is restricted to representatives of W3C member organisations (which pay membership fees on a sliding scale) and invited experts approved by the chair.
ActivityPub became a W3C Recommendation in January 2018, and the protocol work was done by a Working Group. After ActivityPub became an official W3C specification, this Working Group disbanded, and the SocialCG was formed. Since then, the specification has not been formally updated, despite significant implementation experience revealing ambiguities and missing features. The SocialCG has maintained an errata document and developed extensions through the Fediverse Enhancement Proposal process, but these carry no official W3C status. The new Working Group changes this by providing a formal path to update the core specification.
Fediverse advocates regularly point to ActivityPub being a W3C standard as a mark of legitimacy, but for the past seven years the organisational structure that created the protocol has also prevented necessary updates to it. The W3C has done a massive service to the community by holding space for the creation of the protocol in 2018. But since then, the same organisational structure that allowed the protocol to be created also slowed down necessary further work on ActivityPub. This shows up both in errata documents not becoming part of the formal documentation, but also larger work on the Client-To-Server part of the ActivityPub needing more work in order to be suitable for larger adoption.
The new Working Group for ActivityPub changes this situation, and there now a formal path to update the core specification, incorporate errata, and potentially advance new work like LOLA (Live Online Account Portability) to official status. LOLA is a proposal for server-to-server account migration that would allow users to move between ActivityPub servers while retaining both their posts and their social graph. Unlike the current Move activity that only migrates followers, LOLA would enable full content portability. The charter includes LOLA as a potential deliverable, which means it could become an official W3C specification rather than remaining a community proposal.
The are some major complicating factor however, and that is about who actually gets to make decisions. The Community Group lacked power to make official chances to ActivityPub, but it did provide an open place for anyone to participate. In contrast, the Working Group requires participants to either be a paid W3C member or to be an Invited Expert. There are only two organisations that are active in the fediverse that are a paid member of the W3C: Meta and the Social Web Foundation. With the Social Web Foundation also receiving funding from Meta, the company that built Threads now has more institutional standing in ActivityPub governance than any of the organisations actually building open fediverse software. Mastodon gGmbH, Framasoft, and others are not W3C members and cannot participate in the Working Group unless they are invited.
This is by all accounts an extremely funny outcome for a network that aims to be independent of Big Tech’s power.
A few nuances to this. It is unclear if Meta will actually participate in the Working Group, and considering they recently put their Threads<>fediverse integration on maintenance mode, there is a good change that Meta has no interest in actually participating. The Working Group also has yet to communicate who the Invited Experts will be. It could theoretically be that Meta is absent from the group, while Mastodon and Framasoft employees are invited to be part of the Working Group.
Another challenge for the W3C Working Group is that there has long been a disconnect between ActivityPub protocol development and the people creating ActivityPub software. While the above makes it sound that fediverse developers are excluded from the protocol development process, the practical reality is also that the developers of the main fediverse platforms like Mastodon, PeerTube and Lemmy have shown very little interest in engaging with the process when it was openly accessible under the SocialCG. This is illustrated by the meeting last year in which the SocialCG voted to charter a Working Group, where no member of any of the fediverse platform developers was actually present. There has long been a disconnect between the people who develop ActivityPub software and the people who maintain the ActivityPub protocol, with only a few notable exceptions.
This matters because of how W3C standards work. The charter’s success criteria states that updating the Recommendation requires “at least two independent implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites.” The Working Group can propose whatever changes it wants, but for those proposals to become part of the official ActivityPub standard, they need to be implemented in actual software.
LOLA, the proposal to improve account portability, is a clear example of this challenge. Already in fall 2024, Lisa Dusseault, the author of the proposal, said that the specification was ready for developers to start testing implementations. The main bottleneck since then has been getting organisations like Mastodon interested in actually building it. The protocol work is largely done, but what remains is the persuasion and coordination to get implementers interested in using it.
The importance of protocol maintenance and further development of ActivityPub points towards responsibilities for software implementors, especially Mastodon as the dominant ActivityPub implementation. Mastodon’s choices become de facto standards whether or not the project engages with formal standardisation processes. The most clear example is how the Mastodon API has effectively taken over from ActivityPub’s Client-to-Server as the dominant protocol that other softwares have to implement. That position comes with obligations, and when Mastodon doesn’t participate in protocol governance, it creates a vacuum where the largest implementer (in this case also Mastodon) is able to set standards for the rest of the network, but without the governance or formal documentation. When protocol development and maintenance in the Working Group happens disconnected from the largest implementations, the specifications that may not reflect implementation realities.
What this situation reveals is that using network architecture to solve issues of power distribution simply shifts bottlenecks rather than eliminating them. A decentralised protocol does not automatically produce decentralised governance, it also moves power to different, less visible places. The W3C membership structure concentrates formal power in ways that don’t reflect the fediverse’s values, while the implementers who could counterbalance that power have largely opted out of the process. The new Working Group creates an opportunity to address both problems, but who gets to shape the specifications of ActivityPub depends on both who is allowed to participate, as well as who is willing show up and do the work.
https://connectedplaces.online/reports/fediverse-report-148-on-protocol-governance/
