I (Evan) will be at the Wikimedia Hackathon 2026 in Milan, Italy this weekend (May 1-4). I’m especially interested in how we can connect Wikimedia projects and content to the Social Web using ActivityPub. I’ll be holding a session on the topic on Sunday May 3 at 9AM, but I’ll also be available for discussions throughout the weekend.
My hacking project plan is to make an ActivityPub object server for films. There are about 343,000 films in Wikidata, which compares pretty favourably with the 740,000 films in IMDB. There is a JSON-LD interface to Wikidata, but the types used don’t match up with ActivityPub types like Video. So, like places.pub, I’ll set up movies.pub to share an ActivityPub object for every Q-item for a movie, as well as a search endpoint to find films by name.
If I get ahead of the project and I’m not too jet-lagged, I’d like to add an ActivityPub API app to “check in” to a movie that you’re watching (and maybe give a little review). Similar to checkin.swf.pub with places!
If you’re at #wmhack this weekend, please come say hi. I love talking about Wikimedia projects and the open social web.
I (Evan) will be giving talk at Fediforum 26-04 next week, April 28, 2026, on the exciting topic of faking your way through ActivityPub conversations. Here’s the description:
“One of the best bluffers in the field of distributed social networks gives you just enough knowledge about ActivityPub to sound smarter than everyone around you. In this talk, Evan will cover the essential architecture of ActivityPub, what works and what doesn’t, and what is coming up next for the standard. You’ll walk out of this talk with just enough knowledge to speak with confidence about anything at Fediforum.”
If you’ve ever wanted to know what ActivityPub is and how it works, please come along. I hope the event is fun and interesting. Bring questions!
The call for proposals is open for the COSCUP Fediverse track in Taipei, Taiwan. ActivityPub-related software, including server and client implementations, are great topics for the event.
COSCUP (“Conference for Open Source Coders, Users, and Promoters”) is the FOSDEM of East Asia. Run by the Open Source community in Taiwan, it brings together people excited about FOSS across the region.
For the first time, this year, members of the Korean ActivityPub developer community FediDev KR are joining up with FediLUG of Japan to program and run a Fediverse track at COSCUP. This has the potential to be a huge step forward for the Fediverse developer community. Although many major projects, like Fedify and Misskey, are created and promoted in East Asia, distance and language barriers make it hard for East Asian devs to participate in European and North American in-person events.
The Fediverse track is open to proposals about ActivityPub implementations, clients for ActivityPub platforms, ancillary services, libraries and toolkits. But also, as at FOSDEM, talks about the human aspects of Fediverse technology, like moderation, policy and governance, are welcome and encouraged. This event looks like it will cover as much interesting conceptual space as its twin at FOSDEM.
Hong Minhee, hongminhee@hollo.social, was one of the main speakers at FOSDEM’s Social Web devroom this year. Their talk about Fedify was important, but even more important was their effort to bridge the gap between Asia’s and Europe’s Fediverse development communities.
I (Evan) hope that COSCUP brings together many Asian developers, but I also hope that North American and European individuals and teams put in proposals as well. Knitting together these two important communities on the Fediverse requires effort from both sides. That’s why I’m applying to speak (about ActivityPub 1.1), and why I hope to see many familiar faces among the new ones in Taiwan.
tags.pub is a new service under development by the Social Web Foundation. It is a global hashtag server — it lets you follow a hashtag across the Fediverse. There’s lots of information on the tags.pub home page, and I (Evan) did a talk about tags.pub at FOSDEM 2026. This blog post answers some basics about tags.pub.
Social Web Foundation https://tags.pub/user/_____relay_____/inbox (Mastodon) or https://tags.pub/user/_____relay_____ (Pleroma) to your server relays. This is a one-way pipe — your server will send public posts to tags.pub, but tags.pub won’t send all its public data back to you. Instead, your users should follow hashtag accounts to get specific feeds.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.exampleOnce you’re logged in, you can follow someone:
ap follow other@different.exampleOr, 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-cliYou can test that the application installed correctly in your path by running the version command:
ap versionThat 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 Zagidulin, the SocialCG chair who drove the charter editing and review process. Now, the work begins!
One of the project areas of the Social Web Foundation for the last year has been end-to-end encrypted messaging. ActivityPub, the standard protocol that powers the Social Web, has privacy controls, but they do not protect the content of messages from server operators. Encrypted messaging has become a common feature on many social networks since ActivityPub was created, and its lack has inhibited Social Web adoption and public trust in the network.
ActivityPub is extensible, though. As part of our E2EE program, Mallory, Tom and I adapted the Messaging Layer Security (MLS) standard as an extension of ActivityPub to make the MLS over ActivityPub specification. The protocol fits the great MLS E2EE system onto the ActivityPub API and federation protocol.
But a protocol specification is not enough; it must be implemented. That’s why we’re so happy to announce that the Sovereign Tech Fund has commissioned work with the Social Web Foundation to coordinate two new interoperable implementations of MLS over ActivityPub. This investment by the Sovereign Tech Fund will help move the Fediverse towards more privacy for social web users, no matter what server they use.
We decided to partner with two different projects in order to make sure that we’re making an open standard that can work between implementations. With two implementers, we’ll need to communicate clearly about architectural and implementation decisions, and make sure that those decisions end up in the final version of the spec — not in a TODO comment in the source code of a single project.
The first project is Emissary, the great social web application platform behind projects like Atlas and Bandwagon. Ben Pate, Emissary founder, says, “The Emissary Project is deeply committed to the Fediverse, where we are building a free and trustworthy Internet for all 8 billion humans. Delivering on that promise, Emissary is excited to team up with the Social Web Foundation to bring End-to-End-Encryption (E2EE) to the Fediverse. We are eternally grateful for the SWF’s leadership and support, without which this project could not have happened. Our work is already underway, and in 2026 anyone will be able to build E2EE applications on the Emissary platform.”
The second project is Bonfire. Bonfire is a modular framework for building federated apps, with its first app (Bonfire Social) offering a social networking experience enhanced with tools for privacy, trust, and collaboration (such as circles and boundaries).
The maintainers of Bonfire, Ivan Minutillo and Mayel de Borniol, said: “We think that end-to-end encryption should simply be the default for any private communication online. Working with the Social Web Foundation to bring E2EE to ActivityPub marks a crucial step in fostering privacy and trust, and especially in enabling the fediverse to become a safe space for activists and communities to organise, coordinate, and collaborate meaningfully. By making secure, user-friendly messaging a core part of the fediverse, we’re helping lay the groundwork for decentralised networks where people can go beyond talking in the mythical ‘global town square’ and actually organise and accomplish things together.”
This work will happen best if the Fediverse community tracks it closely. We’ll be making updates here on the SWF blog as progress continues. Developers and active users may also be interested in the ActivityPub E2EE Messaging Task Force at the W3C, where the specification is being developed into a report for the Social Web Community group. Finally, we’ll be using the #JustBetweenUs hashtag to share progress and ideas, so you can follow it to see what’s been happening.
The schedule for the Social Web Developer Room at FOSDEM 2026 is starting to be populated as the speakers confirm their availability. We had a tonne of great submissions for this year’s track, and even with double the time from last year, we still had to leave some great talks on the cutting room floor. But we still managed to fit in 24 great talks, large and small. We’re going to see some additional events happening as FOSDEM 2026 gets nearer. Watch the #SOCIALWEBFOSDEM hashtag for more news and events.
We were excited to see the recent release of Ghost 6 with ActivityPub features. The Ghost team have been an active participant in our Long-form Text project. And Mallory’s newsletter the Internet Exchange just published about why they use Ghost. John O’Nolan, founder and CEO of Ghost.org, was kind enough to answer our questions about the software and its community.
SWF: For our readers who don’t know Ghost, how would you describe the platform?
JO: Ghost is an independent publishing platform for people who take writing seriously. We’re open source, non-profit, and built to give creators complete ownership of their content and their audience. We’ve helped indie publishers generate over $100 million in revenue from sustainable modern media businesses like 404Media, Platformer and Tangle News.
SWF: Tell us about your user community. Can you paint a picture of them with a broad brush? What kind of people choose Ghost?
JO: Ghost attracts people who care about owning their home on the internet, rather than having another profile on a social media platform. Our publishers range from solo journalists and creators, to established news outlets and large businesses. They value independence, and they’re willing to do the work to maintain control of their brand, distribution, data, and relationship with readers.
SWF: What is it like to be a Ghost user in 2025? What kind of problems are your users facing today?
JO: The big challenge today is the same one that’s haunted independent publishers for two decades: discovery. You can own your platform and serve your audience beautifully, but if people can’t find you, none of it matters. Email newsletters have been a solid answer, but they’re still dependent on deliverability and inbox placement. Algorithms on social platforms actively suppress links now, so sharing your work there is like shouting into a hurricane.
SWF: Tell us about your experience with ActivityPub. Why did you decide to add ActivityPub support to your software?
JO: Ghost has had support for delivering content by email newsletters for a number of years, and email has remained an unassailable distribution platform for publishers because it’s an open protocol. No company controls your email list except you, so it’s one of the best investments you can make. ActivityPub is now doing the same thing for social technology. It allows publishers to own and control a distribution channel that allows their work to spread and be discovered by others. For the first time, you can publish independently and grow faster than ever before.
SWF: What stack is Ghost built on? What development tools does your team use?
JO: Ghost is all built in modern JavaScript; mainly Node and React. Our ActivityPub service is built on Fedify, and everything we build is released under an open source MIT license. Our development tools are constantly evolving, and now more quickly than ever before with the advent of AI tools, which seem to change on a near weekly basis.
SWF: What was the development process like?
JO: Challenging, honestly. ActivityPub is beautifully designed but the spec leaves room for interpretation, and when you’re building something new, there’s no roadmap. Building interoperability between other platforms, who’ve all interpreted the spec in their own unique ways, has been a real challenge. The approach we took was to ship early versions as quickly as possible to beta testers so we could learn as we go, using real-world data and issues to guide our process. We’re in a good spot, now, but there’s still a lot to do!
SWF: Ghost produces long-form blog posts, articles and newsletters. How was the experience adapting Ghost articles to the microblogging interfaces of Mastodon and Threads?
JO: In some ways really easy, and in other ways quite tricky. We’re at a pretty early stage for long-form content on ActivityPub, and the majority of other products out there don’t necessarily have interfaces for supporting it yet. The easy part is that we can provide fallbacks, so if you’re scrolling on Mastodon you might see an article title and excerpt, with a link to read the full post – and that works pretty well! The dream, though, is to make it so you can just consume the full article within whatever app you happen to be using, and doing that requires more collaboration between different platforms to agree on how to make that possible.
SWF: You’ve been an active participant in the ActivityPub community since you decided to implement the standard. Why?
JO: ActivityPub is a movement as much as a technology protocol, and behind it is a group of people who all believe in making the web a weird, wonderful open place for collaboration. Getting to know those humans and being a part of that movement has been every bit as important to the success of our work as writing the code that powers our software. We’ve received incredible support from the Mastodon team, AP spec authors, and other platforms who are building ActivityPub support. Without actively participating in the community, I don’t know if we would’ve gotten as far as we have already.
SWF: Ghost has implemented not only a publishing interface, but also a reading experience. Why?
JO: The big difference between ActivityPub and email is that it’s a 2-way protocol. When you send an email newsletter, that’s it. You’re done. But with ActivityPub, it’s possible to achieve what – in the olden days – we fondly referred to as ‘the blogosphere’. People all over the world writing and reading each other’s work. If an email newsletter is like standing on a stage giving a keynote to an audience, participating in a network is more like mingling at the afterparty. You can’t just talk the whole time, you have to listen, too. Being successful within the context of a network has always involved following and engaging with others, as peers, so it felt really important to make sure that we brought that aspect into the product.
SWF: Your reader is, frankly, one of the most interesting UIs for ActivityPub we’ve seen. Tell us about why you put the time and effort into making a beautiful reading experience for Ghost.
JO: We didn’t want to just tick the “ActivityPub support” checkbox – we wanted to create something that actually feels great to use every day. The idea was to bring some of the product ideas over from RSS readers and kindles, where people currently consume long-form content, and use them as the basis for an ActivityPub-native reading experience. We experimented with multiple different approaches to try and create an experience with a mix of familiarity and novelty. People intuitively understand a list of articles and a view for opening and reading them, but then when you start to see inline replies and live notifications happening around those stories – suddenly it feels like something new and different.
SWF: If people want to get a taste of the kind of content Ghost publishers produce, what are some good examples to follow?
JO: Tough question! There are so many out there, and it really depends on what you’re into. The best place to start would be on ghost.org/explore – when you can browse through all sorts of different categories of creators and content, and explore the things that interest you the most.
SWF: If I’m a Fediverse enthusiast, what can I do to help make Ghost 6 a success?
JO: Follow Ghost publishers and engage with their content – likes, replies, reposts all help! Most importantly, help us spread the word about what’s possible when platforms collaborate rather than compete. And if you’re technical, our ActivityPub implementation is entirely open source on GitHub – contributions, bug reports, and feedback make the whole ecosystem stronger.
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.