- Evan Prodromou (Social Web Foundation)
ActivityPub defines a "Social API" that lets applications act on behalf of a user with a social networking platform.
The API is defined in several sections of the specification:
- Section 3: Objects
- Section 4: Actors
- Section 5: Collections
- Section 6: Client to Server Interactions
Sections 3, 4, and 5 define a read-only interface to social data. Section 6 defines a write interface to make changes to social data by creating new Activity objects and implementing their defined side effects.
The ActivityPub API provides an extremely flexible interface for building social applications. Because unlimited kinds of activities can be created by clients, novel applications can be built on top of the ActivityPub network.
Unfortunately, the ActivityPub API has not been widely implemented in its read-write form, even by social platforms that implement the ActivityPub federation protocol.
Instead, they often implement platform-specific APIs, with a narrow range of functionality. Mastodon, for example, implements the Mastodon API, which focuses primarily on microblogging. Threads implements the Threads API. Many other ActivityPub implementers have APIs that clone the Mastodon API, to make it easier for users to adapt third-party Mastodon clients to their platforms.
Sections 3, 4 and 5 of the ActivityPub specification overlap with the federation protocol, such that many platforms that implement the federation protocol effectively have an read-only API for clients. This functionality is rarely adapted for client applications, though.
Section 6, for creating new activities, is not widely implemented, either by clients or by servers.
Consequently, using the ActivityPub API to drive innovation in social software development is disappointingly slow or non-existent. Client developers don't build on top of the ActivityPub API, because so few servers and actors support it. Server developers don't implement it because there are few to no clients.
For users, this results in narrowly-focused social platforms that implement only some subset of the social functionality they can experience elsewhere: microblogging, events, image-sharing, or videos. The server developers implement all the end-user functionality and the full federation protocol.
The primary goal of this task force is to encourage an innovative ecosystem where client developers can build interesting and novel applications with the ActivityPub API, and server developers can provide unexpectedly interesting experiences for their users. The method is to clear the path for both client and server developers to implement the standard.
The following user stories describe important work for this task force. User stories are tracked in the task force GitHub repository as issues.
- OAuth profile: "As an ActivityPub API client developer, I need a standard profile of OAuth to use for authorising my app to API servers, so I don't have to create custom code for every different API server."
- Server features: "As an ActivityPub API server developer, I need a list of recommended features to implement, so that I can support API clients correctly."
- Feature discovery tips "As an ActivityPub API client developer, I want to know how best to discover API features like media upload or readable inboxes, so that I can have reliable discovery code in my client software and have reasonable fallback strategies if features are missing."
- Rate limiting "As an ActivityPub client developer, I want a reliable and standard way to discover rate limits in an ActivityPub API server, so I can avoid unexpected failures for my users."
- CORS "As a Web client developer, I want to have reliable expectations for CORS for the ActivityPub API, so that I can use API endpoints from the browser without going through a proxy server."
- Media upload "As an ActivityPub API client developer, I want to have a standard definition of the media upload endpoint, so that I can upload media to servers."
- Generic versus specialised servers "As an ActivityPub API client developer, I want to know if an API server will process and distribute arbitrary Activity objects or just a specific subset, so that I can know whether the server will work for my application."
- Client libraries "As an ActivityPub API client developer, I want a library to use in my preferred programming language, so I don't have to develop directly to the REST API specification with low-level HTTP interfaces."
- Push delivery "As an ActivityPub user, I want data pushed from the server to my client device, so I don't have to reload a collection just to see if there's anything new."
- Remote object access "As an ActivityPub client developer, I want a reliable method for accessing objects on remote servers with the user's authorization, so I can read private or followers-only data."
- Collection membership As an ActivityPub client developer, I want to have a way to check if an object is a member of a collection, so I don't have to load the whole collection to search for the object."
- Determining ActivityPub API support "As an ActivityPub API client developer, I want to have a reliable way to tell if an actor supports the ActivityPub API, so I can set my client to read-only mode if not."
- Filter collection by member type "As an ActivityPub API client developer, I want a way to filter a collection by the type of the members, so I can show the members that are relevant to my application."
- Find activities related to a single object "As an ActivityPub client developer, I want a fast way to filter a collection of activities by the id of the object property, so I can find activities related to a particular object."
- Filter collection by type of the object property "As an ActivityPub API client developer, I want to filter a collection by the type of the object, so I that I can make an application that specializes in a particular kind of object."
- Fallback representations "As an ActivityPub API client developer, I want rules for a fallback representation for unrecognized activity or object types, so I can show a stand-in in a stream or other representation."
- Separate notifications and home feed "As an ActivityPub API client developer, I want a 'home feed' collection for content-oriented incoming activities like Create, Question and Announce, so that I can show my users the most important content from their networks." "As an ActivityPub API client developer, I want a 'notifications' collection for less directly important incoming activities like Like, Follow and Update, so that my users can see what's happening without it crowding up the 'home feed'."
- Content search "As an ActivityPub API client developer, I want a content search endpoint, so that I can find matching content by keyword."
- Actor search "As an ActivityPub API user, I want to be able to search for actors by keyword, so I can find my friends, family, colleagues, neighbours, influencers or publications that I like."
- Prefix search "As an ActivityPub API user, I want to have a prefix search feature available, so I can mention someone partially and let my client autocomplete the rest of their address."
- Domain blocking "As an ActivityPub API user, I want to have a way to block an entire domain, so that I am not harassed by users on a poorly-moderated server."
- Mute "As an ActivityPub API user, I want to be able to mute another actor, so we can stay connected but I don't see their activities in my inbox or in other collections."
- Actor identity in OAuth authorization flow "As an ActivityPub API client developer, I want to get an actor identity that I can use at the end of the authorization flow, so I know which actor actually logged into my application."
- Standard error messages "As an ActivityPub API client developer, I want to have an agreed-upon format for error messages from the server, so I can give more context to my user about why their activity didn't work than just saying 'That didn't work'".
- Manually approved followers "As an ActivityPub API client user who manually approves followers, I want a list of my current pending incoming follow requests, so I can decide whether to accept, reject, or ignore them." "As an ActivityPub API client user, I want a list of my current pending outgoing follow requests, so I can decide whether to keep waiting or give up and undo them."
- Actor Profile Edit "As an ActivityPub client user I would like to be able to edit my Actor profile: changing the avatar, display name, description, etc"
- Local Feed "As an ActivityPub API client developer, I want a feed of public activities from other actors on the same server."
- Moderation "As an ActivityPub API client developer, I would like to access a servers moderation queue. Allowing users with appropriate permissions to act upon flagged accounts and objects"
- Trending hashtags, posts, and links "As an ActivityPub API client user, I would like to see which Hashtags, Posts, Links are trending on my server, and on the wider fediverse"
- Account recommendations "As an ActivityPub API client user, I would like to access a list of recommended accounts".
- Account directory "As an ActivityPub API client developer, I would like to access a complete list of (public) actors from a given server".
- Define a new, incompatible API to compete with the one described in the ActivityPub recommendation
- Adapt another standard API to the ActivityPub network
- Standardize a platform API, like the Mastodon API, for general use
TBD
The task force will create community group reports for each of the user stories in the goals. Some of these may be combined into a single report.
N/A
The group will create a report defining the expected flows and discovery mechanisms for OAuth 2.0.
There is an example Web client that can be used to test server implementations.
There is a proposed report for push delivery: Server-Sent Events For the ActivityPub API.
TBD
TBD
TBD
The following platforms inspire this approach:
- Facebook Platform
- OpenSocial, in particular the Activity Streams and Embedded Experiences API
- ATProto's use of lexicons
