ActivityPub is the decentralized social networking protocol.

It provides a client to server API for creating, updating and deleting content, mechanisms for building a social graph, as well as a federated server to server API for delivering notifications and subscribing to content.

It is based on the ActivityStreams 2.0 (AS2) data format, which is a JSON-LD format for describing social activities. Because AS2 is extensible with new types of activities, objects, and properties, ActivityPub is also extensible. You can build many different kinds of social applications on top of ActivityPub.

ActivityPub was developed by the Social Web Working Group of the World Wide Web Consortium. It was standardized in 2018 as a W3C Recommendation.

• The ActivityPub specification is the official document that describes the protocol.
• The errata pages shows known errors in the specification.
• The Editor's Draft incorporates the corrected errata directly into the specification text.
• The SocialCG is the community group that maintains the specification. It meets regularly to discuss the specification and its implementations.
• The ActivityPub Primer gives deeper explanations of topics described in the specification.
• The ActivityPub WebFinger profile describes how to use WebFinger with ActivityPub.
• The ActivityPub HTTP Signatures profile describes how to use HTTP Signatures with ActivityPub.
• The ActivityPub Data Portability task force describes how to use ActivityPub for data portability.

The currently active editors of the AP specification(s) are:

• Evan Prodromou

The main way to make contributions, ask questions, or report errors is to make a GitHub issue. Because the specification is a published W3C Recommendation, it is not helpful to make pull requests to the repository.

The AS2 vocabulary provides the basic data model for ActivityPub. Questions or issues about the AS2 vocabulary should be directed to the AS2 repository. If you're not sure whether an issue should go there or here, feel free to add it here and it will be discussed and moved if necessary.

Because the document is a published W3C Recommendation, the process for making changes to the specification is more formal than for other documents.

Explanations, tips and clarifications usually go in the ActivityPub Primer. If you have a question about how something works in ActivityPub, open an issue and we can discuss adding it to the primer.

To handle editorial errors like spelling or grammar mistakes, unclear or ambiguous text, factual errors in text, or syntax errors in examples, we have several steps.

1. Make a GitHub issue.
2. The editor will make a proposed erratum for review by the SocialCG.
3. At a future SocialCG meeting, the group will review the proposed erratum and decide whether to accept it. Accepted errata are added to the errata page.
4. The editor will incorporate the errata into the Editor's Draft.
5. Errata are periodically deployed to the main ActivityPub specification.

Backwards-compatible changes to ActivityPub include the following:

• Adding new kinds of activities
• Adding new kinds of objects
• Making mandatory behaviours optional
• Adding new properties to existing types

Backwards-compatible changes should usually be implemented as extensions to the specification. The Activity Streams 2.0 primer describes the extension architecture for ActivityStreams 2.0. The Extensions Policy describes the process for incorporating popular extensions into the main Activity Streams 2.0 context document.

The Fediverse Enhancement Proposals process is a lightweight collaboration process for creating and documenting Activity Streams 2.0 extensions (and other changes to the Fediverse). It's a good place to start if you're considering a backwards-compatible change.

There are many ideas for backwards-compatible changes to ActivityPub that have not yet been written up as a FEP or other document. These are marked Needs FEP in the ActivityPub GitHub issue repository, and contributors are welcome to submit a FEP on the topic. Note that issues may be closed without the FEP being created; that does not mean that the FEP is no longer needed.

Some backwards-compatible changes cannot be implemented as extensions. They require a new version of the core document; see below for how that process works. Examples include:

• Loosening behavioural requirements
• Deprecating existing properties or behaviours

Breaking changes to the specification require chartering a new working group at the W3C. It also requires making changes in dozens of ActivityPub implementations and tens of thousands of running servers. Breaking changes also cause disruption on the working network, since implementations and servers will upgrade gradually, on their own pace, not all at once. This is a lot of work, inhibits the point of the protocol (connecting people and communities), and is not done lightly.

Examples of such changes:

• Making optional features mandatory
• Forbidding optional features
• Forbidding required features

To propose a breaking change to ActivityPub, add a new issue. It will be discussed and flagged for the next version of ActivityPub.

These lists are externally maintained and initiated.

• delightful activitypub development: developer tools
• delightful fediverse apps: ActivityPub federation protocol implementations
• FediDB software: periodically polled software census, with statistics per implementation