Today the W3C standards organization announced a new working group to advance the ActivityPub and Activity Streams standards. The Social Web Foundation, as a W3C member organization, will be participating in the group. The working group’s goal is to release a backwards-compatible iteration of each specification in Q3 of 2026.
Activity Streams was released in 2017, and ActivityPub was released in early 2018. Since that time, the experience of hundreds of implementers and millions of users has shown places that the specifications are confusing or unclear, or missing features. Some problems have been documented with errata, but others require more work. The Next Version tag in the ActivityPub GitHub issue repository gives some good examples of topics to be considered. The new Social Web Working Group will provide revisions of these documents to make them easier to use for implementers.
ActivityPub is an actively used protocol with millions of users and billions of notes, images, video and audio files published. Standards work on ActivityPub will necessarily be evolutionary, not revolutionary, and will incorporate backwards compatibility. Developers can confidently keep working on ActivityPub today without worrying about breaking changes in the future.
The Social Web Working Group will work closely with the Social Web Community Group, the organization that has been stewarding ActivityPub and its extensions since 2018. The Community Group will remain the focal point for innovative developments extending ActivityPub into different areas like geosocial applications or threaded forums, while the Working Group will concentrate on the core documents.
One Community Group document that will be moving into the Working Group is LOLA, the live data portability spec that originated in the CG’s Data Portability Task Force. LOLA lets users move from one ActivityPub server to another while retaining all their social connections, their content, and their reactions. It’s a great improvement for data portability on the social web.
The Social Web Working Group will consist of representatives of W3C member organizations and invited experts from the standards and development community. The group will be chaired by Darius Kazemi, longtime contributor to the ActivityPub developer community. Meetings and proceedings will be public, and developers can review the work happening in the ActivityPub GitHub repository.
Thanks to everyone who’s done the work getting this charter to completion; especially Dmitri Zagidulin, the SocialCG chair who drove the charter editing and review process. Now, the work begins!
Hey, all! I’m seeking some help testing an application I whipped up for the Geosocial task force of the W3C Social Web Community Group. It’s called https://checkin.swf.pub/ , and it’s a barebones checkin service, similar to Swarm, but implemented as a pure Web client. You can watch the application in action.
It logs into your account on an ActivityPub server using OAuth 2.0. It then reads your inbox, filtering the activities there to only show geosocial ones. You can use the geolocation services in the browser, and the places.pub service for a place vocabulary, to find nearby places. You can then “check in” to one of the places, with a note, and control of the privacy of the activity.
Geosocial activities are part of the core Activity Vocabulary that underlies ActivityPub. But, they’re not as widely implemented as other activities in the vocabulary. This app is trying to change that, by making them available on the network, and making it easy to create them.
To test the client, your service will need to support:
To test federation, your service will need to support:
As of this writing, Mastodon does not work for either of these. If you want to test receiving federated messages, follow me on evan@onepage.pub . I’ve been using it a lot!
Code for the checkin application is here: https://github.com/social-web-foundation/checkin
This is my second ActivityPub API client (ap, the command-line client, was my first), and my first one for the Web. I found this process really fun and invigorating. I was able to create a new kind of social networking application (well, new on the Fediverse…) purely from the client side. The app saves no data to the server; everything is done in the browser.
Please reach out on GitHub or comment here if you want to work on interoperability. I’m happy to help debug connections if needed.
I want to draw attention to an administrative process at the W3C Social Web Community Group (SocialCG), the standards group that manages ActivityPub and Activity Streams 2.0 and a number of other open social networking standards. The group is considering a new charter to define how decisions are made and how the members work together. This might seem like a minor process, but it’s actually part of a bigger deal for the Fediverse. To see why, you need to understand the structure of the W3C.
The W3C (World Wide Web Consortium) is the standards organization that specifies the Web platform, like HTML (kind of), CSS, and RDF. It also is the organization that standardized ActivityPub and AS2 in 2019. The W3C process requires a special kind of group, called a Working Group, to create official recommendations on the part of the organization. Working Groups can have members nominated by the W3C member organizations, as well as some Invited Experts.
The W3C has another structure, called a Community Group, that’s much looser. Anyone can join a community group, as long as they sign the Contributor License Agreement, which grants a copyright and patent license to the work they do with the group. Community Groups don’t produce formal recommendations in the W3C; they can produce Community Group Reports, which can be documents, software, or really anything.
So, the Social Web Working Group created and edited ActivityPub and AS2 back in the mid-2010s. The group had a charter that extended into 2018; it was extended to early 2019 so the work on ActivityPub could be finished. The working group was then disbanded. A new Community Group, the SocialCG, had been started in 2017. It took over the process of supporting new extensions to AP and AS2, as well as maintaining the errata for the two main documents. Importantly, it can’t make major changes to the documents themselves — that requires a working group.
The experience of developers and users over the last decade in using ActivityPub has pointed out some real needs for updates to the documents. The W3C staff have asked the SocialCG to draft a charter for a new working group that could make backwards-compatible changes to these documents — adding clarifications, and possibly including new features. This would be great for the specifications, great for the Social Web, and great for the Internet at large.
The problem is that there isn’t a clear relationship between the boundaries of the new working group and the boundaries of the community group. What input would members of the community group have in the editing of the updated ActivityPub documents? Especially given that W3C members tend to be more commercial and institutional than the mostly Open Source developers who work in the SocialCG, there is a concern that a new Social Web Working Group would prioritize the needs of corporate developers with lots of resources, at the expense of Open Source devs making code for small communities.
The answer we’ve landed on is to implement a stage process, in which new ideas are initiated and documented as Community Group Reports before the Working Group takes them up for possible inclusion the main recommendation documents — or becoming new recommendations on their own. This process has worked well in other Community Groups at W3C, and the W3C staff is really supportive of it.
One problem with this process for the SocialCG is that we never adopted rules for how we make decisions when we started the group. We agreed casually to use the same consensus-based mechanisms we’d used in the Social Web Working Group, but never put together an official charter for the group. This casual structure has worked well for a long time, but in order to set up this more formal staging process, we need to have a more formal decision-making process.
The good news is that the norm in the W3C, as in most Internet standards organization, is to use consensus-based decision-making. So, the new SocialCG proposed charter has a lot of casual consensus, too, as well as pretty open participation on a very peer-oriented basis. It’s about the minimum structure you need to have a long-running organization.
So, let me recap: we want updated, backwards-compatible versions of ActivityPub and Activity Streams 2.0 with more clarity and maybe even new features. In order to get those, we need a Working Group. In order to get that, we need to establish a stage process. And in order to adopt the stage process, we need to have a new CG charter. So: CG charter leads to stage process leads to WG leads to new specs leads to new features.
The Community Group intends to consider approving the new CG charter at its January 2025 meeting. So, people interested in ActivityPub, standardization, and group dynamics in general are invited to review the documents and submit GitHub issues or comment on existing issues. If you’re not already a member of the SocialCG, you can join in a just a few minutes. It’s also reasonable for non-members to comment or make suggestions.
This work is complicated, but it’s also fascinating, and it is an exciting part of putting ActivityPub on a solid footing for the future.
Social Web Foundation