ActivityPub API Task Force
/2025-10/session/5-b/
Topics:
Convener: Evan Prodromou (@evanp@socialwebfoundation.org)
Participants who chose to record their names here:
- James Marshall (@jamesmarshall@sfba.social, james@jmarshall.com)
- Eugenus (@ujeenator@ujeenator.net)
- Julian Lam (@julian@activitypub.space)
- Christoph Witzany (@christoph@allpeep.com)
- Mayel (@mayel@bonfire.cafe)
- Anca (@anca@allpeep.social, @anca@mastodon.xyz)
- Anuj Ahooja (@quillmatiq.com, @quillmatiq@mastodon.social)
- Matthias Pfefferle (@pfefferle@mastodon.social)
- Michelle Hughes (@MegaMichelle@a2mi.social)
- Darius Kazemi (@darius@friend.camp)
- Cagan Mert Islek (@islekcaganmert.me)
Website: Task force repo: https://github.com/swicg/activitypub-api
Notes
- The problem:
- Lots is happening in the Server-to-Server ActivityPub space, but less is happening on the Client to Server RW mode
- Devs are implementng against the Mastodon API instead of the AP standard C2S
- AP C2S vs Mastodon API is like POP vs IMAP
- The API Task Force is intended to implement the standard API and make this API easy to use
- Task force repo: https://github.com/swicg/activitypub-api
- Visit the Issues tab to see the developing user stories
- Next step: working on candidate solutions
- Task force repo: https://github.com/swicg/activitypub-api
- Julian: “Love the idea of a platform-agnostic API, would pick it 10 times out of 10”
- I want to implement ActivityPub API instead of Mastodon, but there’s an Assertion that C2S is deficient? How?
- Evan: No implementation-specific methods (obviously), too general for some implementors’ usage cases
- Eugenus - any feedback from large implementors about this API?
- Mayel: we’ve recently realised that C2S is actually perfectly suited for A2S (app-to-server) 🤯 so non-federated apps (including server apps) can very easily federate their activities by just implementing 1 POST request to 1 endpoint rather than implementing all of ActivityPub
- Evan: Having this standard API encourages creating some innovative clients,
- Mayel: or easily adding AP support to non-federated FOSS apps (whether server apps or web/mobile apps, doesn’t matter)
- Michelle: C2S implies “thick clients” vs “thin clients”. Mastodon is concerned that C2S doesn’t have “home” feeds and block/mute, but that’s because the creation of home feeds and block/mute are a job of the client. Mastodon is trying to be both a client and a server. An ActivityPub app could be implemented so that there is an application that does nothing but ship ActivityPub posts around without interpreting semantics, in the way that Sendmail ships SMTP posts around. An ActivityPub app could have a separate application that acts as the Client. This could be on a phone or on a web app, and that talks to the ActivityPub server using C2S, in the same way that a mail app talks to the mail server, much like using POP or IMAP. The way Mastodon is constructed now, it’s got Roundcube and Sendmail, trying to combine it into one application.
- Someone recommended this as a generic ActivityPub server that implements S2S and C2S and makes no attempt to interpret semantics or be a client: https://rdfpub.org/
- Cagan: Instead of providing raw access to apps, why not create an SDK where people can implement new functions if they need and stick with already existing functions? This way we can also get EVM and AT Protocol developers consider switching to fediverse. Especially after concerns about Bluesky and overload issue of Ethereum chain.
- Matthias: Technical question: Where do you subscribe to a feed? Where is the readable object that represents a “feed”?
- Evan: A collection of objects is not part of the API (e.g. “All of Evan’s posts”, “All of Evan’s photos”). Part of the task force work is to look at how we might provide a filter for “only photo posts”
- Julian: What is the bare minimum that I need to support? Ingesting via inbox and output via outbox?
- Evan: essentially, yes.
- Anca: How do we get involved?
- Comment on the Github Repo
- www.w3.org/groups/cg/socialcg/calendar/ <– Meeting calendar
- https://www.w3.org/community/socialcg/ <– Sig
- Manton: Something that works well in the Micropub API is that there is a very simple “create a post” starting point, and then other optional features layered on from there. I think C2S could benefit from a few minimal recommended features that client apps could start supporting even as they also support Mastodon or other proprietary APIs. A way to bootstrap some C2S basics without getting overwhelmed with porting everything. (Thanks Evan!)
- Darius: I want to say there is an overloading of “client” here for mental models. Matthias seemed to be asking “what is the endpoint the app on my phone should talk to in order to get a coherent feed?” The answer there is that the feed management and aggregation shouldn’t happen on the phone! the phone should talk to an application server, and the application server is the “client” that tracks the inbox and handles state updates. I think breaking things into C2A, A2S, S2S might be where we need to go. Bluesky solves the problem of local apps not needing to manage complicated feed state via independent feed generators that do this as their own thing, but we could say the “application” server layer manages that, basically generating feeds for users off-device
- Cagan: What if an app behaves bad—sending damaged activities, spamming remotes, inappropiate or wrong contenrt—how to avoid this without blocking the apps’ intended behaviors?