ActivityPub

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 is maintained by the Social Web Working Group of the World Wide Web Consortium. Key info 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 Social Web WG is the working 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 Social Web Incubator Community Group also maintains: The ActivityPub WebFinger profile describes how to use WebFinger with ActivityPub. The ActivityPub HTTP Signature profile describes how to use HTTP Signature with ActivityPub. The ActivityPub Data Portability task force describes how to use ActivityPub for data portability. 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. 1. Make a GitHub issue. 2. The editor will make a proposed erratum for review by the Social Web Working Group. 3. At a future Social Web WG 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 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. These lists are externally maintained and initiated. delightful activitypub development: developer tools delightful fediverse apps: ActivityPub federation protocol implementations FediDB software: periodically polled softwar