Evan Prodromou

As part of my book “ActivityPub: Programming for the Social Web“, I created a coding example to show how to program for the ActivityPub API. ap is a command-line client, written in Python, for doing basic tasks with ActivityPub.

For example, you can log into a server using this command:

ap login yourname@yourserver.example

Once you’re logged in, you can follow someone:

ap follow other@different.example

Or, you could post some content:

ap create note --public "Hello, World"

This isn’t enough to have a real social networking experience, but I think it’s pretty useful for testing an ActivityPub API server, or automating some repetitive tasks.

I should note quickly here that not all ActivityPub servers support the ActivityPub API. It’s an under-utilized part of the ActivityPub standard. In particular, Mastodon, Threads, Flipboard, and other services don’t support the API. There’s a pretty good list of servers and clients that do support the API in this Codeberg issue.

Suffice it to say, unless you’re actively working with one of those platforms, or you are writing your own, you’re not going to get much use out of ap. It will probably give you an error message like “No OAuth endpoints found” if it can’t use the service.

I’ve never packaged ap for distribution; it was always supposed to be example code. But given the recent interest in the ActivityPub API, including the work going on in the ActivityPub API task force, I decided to get it into shape for installation by developers working on other apps. My friend Matthias Pfefferle of Automattic asked me about it when we were at FOSDEM this year, and I was embarrassed to see how difficult it was for him to use.

So, I’ve made two big upgrades to the package. The first was actually making it a package, and distributing it! I upgraded the package management framework to uv, which seems like a good bet for now, and pushing the application to PyPI, the Python Package Index. It’s visible at https://pypi.org/project/activitypub-cli/ now. (Note: different package name from the command name! The PyPI “ap” package name was taken a while ago.)

You can now install the application in one shot with this command on a computer that has Python on it:

pipx install activitypub-cli

You can test that the application installed correctly in your path by running the version command:

ap version

That should show the same version as is currently on the pypi.org page for the project.

The second change was implementing the current OAuth 2.0 profile best practices. I’ve upgraded the login flow so it tries a lot of different options for identifying itself to the server: CIMD, FEP d8c2, and Dynamic Client Registration. It tries to do them in preferential order; it uses permanent, global client identifiers before dynamic ones.

I’m especially interested in testing this command-line client against other servers. If you’re developing an ActivityPub API server, please install the ap command and try it out against your (development!) server. Report a bug if it doesn’t work well, or send me a DM at @evanprodromou if it works OK. Given time, I think ap can be a useful first smoke test for ActivityPub API implementations.

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@social.coop, the SocialCG chair who drove the charter editing and review process. Now, the work begins!

I’m going to be participating in the Growing the Open Social Web workshop at Fediforum on March 3, 2026. I’m excited to talk to other people who care about the Fediverse about ways to connect more people through ActivityPub.

Fediforum invited attendees to publish position papers before the workshop. SWF has a number of hypotheses about growth of the social web; I’ll try to summarise some of them here.

• Growth can’t come at the expense of privacy. People currently on the Fediverse must have the tools they need to preserve their privacy as the network grows. This means privacy from other users, as well as privacy from new platform operators. Expanding the options for private interactions on the Fediverse, like end-to-end encrypted messages and private groups, is necessary for preserving privacy as the user base and platform list expands.
• Connecting platforms to the Fediverse is our most efficient way to grow. There are already billions of people on social platforms across the Internet. Getting these platforms to let users publish to the Fediverse, as well as having two-way interactions with remote users, lets people share in the benefits of the Fediverse with a platform and interface that they’re already used to. Even when brand new social platforms adopt ActivityPub, they bring their new features and users.
• Connecting communities helps us grow fast and stay cohesive. Bringing formal and informal communities onto the Fediverse is a great way to enable a lot of new users quickly. By formal communities, we mean organized groups like clubs, universities and schools, professional societies, enterprises, or local and regional governments. These groups can set up their own places on the Fediverse, like Mastodon servers, and provide user accounts for all their members. (One great way to connect formal communities is to Fediverse-enable the community platforms they already use.) These new Fediverse users have the kind of connections in place that retain active users, as well as the support they need to use the Fediverse. More informal communities, like people sharing the same profession, fans of a particular hobby, or users of a language or technology, can be great additions to the Fediverse, but these groups are less cohesive and less likely to bring their own infrastructure.
• People come to social networks for existing social ties. Bringing on new users one-by-one is the most difficult way to grow this network. The best way to engage new users on the network, and to keep them active and interested, is to make sure they can connect to people they already know and care about. That may be friends, family, colleagues and neighbours, or brands, creators, and publications they recognise. Our onboarding processes for Fediverse users need to encourage the social contacts so that people feel a reason to stick around for day 2, 7, and 30.

We’re looking forward to engaging with the Fediforum community on these and other topics. We’ll see you on March 3!

I want to share some information about a repository we just published. ap-components is a set of Web Components for building interfaces for the ActivityPub API. I built it as I was making a sample application for handling the acct: URI scheme. I found myself making more and more components for the UI, and realised that they would probably be useful for other applications, too.

The library is available on npm at @socialwebfoundation/ap-components. It currently covers some of the simplest ActivityPub data, but I hope to expand it to give visibility to other types of objects and activities. Please feel free to try it out and let us know if it’s helpful for your work.

We are happy to see the patent non-aggression pledge published by Bluesky today.

Software patents and related intellectual property can have a dampening effect on innovation in an entire application domain, such as distributed social networks. They make developers use complex, roundabout methods to do simple tasks, just to avoid the appearance of using a technique that may or may not be patented by another company now or in the future.

By offering this pledge, Bluesky makes it that much easier for everyone in this entire area — not just those working on ATProto or closely linked technologies — to more safely explore techniques without worrying about patent trolls pouncing on them or their users sometime in the future. It was a brave and generous step on their part.

The ActivityPub specifications, including Activity Streams, are covered by the W3C Patent Policy which gives good protection from patents by the specification creators and the W3C member organizations. Patent licensing is an important advantage of working in an open standards organization.

With the Bluesky patent pledge, another distributed social networking protocol and its related technologies are free to explore and re-use with less worry about paying royalties to a patent holder. It’s a good step forward in the ecosystem.

We hope companies and projects in other distributed social network ecosystems follow up on this step by releasing their own patent pledges, or developing their standards in an open standards organization like the W3C.