ActivityPub is a protocol and open standard for decentralized social networking. It provides a client-to-server (C2S) API for creating and modifying content, as well as a federated server-to-server (S2S) protocol for delivering notifications and content to other servers. ActivityPub is the defining standard of the Fediverse, a decentralised social network of various social interaction models, and content types, which consists of independently managed instances of software such as Mastodon, Pixelfed and PeerTube, among others.
~11 min read
ActivityPub is a protocol and open standard for decentralized social networking. It provides a client-to-server (C2S) API for creating and modifying content, as well as a federated server-to-server (S2S) protocol for delivering notifications and content to other servers. ActivityPub is the defining standard of the Fediverse, a decentralised social network of various social interaction models, and content types, which consists of independently managed instances of software such as Mastodon, Pixelfed and PeerTube, among others.
ActivityPub is considered to be an update to the ActivityPump protocol used in pump.io, and the official W3C repository for ActivityPub is identified as a fork of ActivityPump. The creation of a new standard for decentralized social networking was prompted by the complexity of OStatus, the most commonly used protocol at the time. OStatus was built using a multitude of technologies (such as Atom, Salmon, WebSub and WebFinger), a product of the infrastructure used in GNU social (the originator and largest user of the OStatus protocol), which made it difficult to implement the protocol into new software. OStatus was also only designed to work with microblogging services, with little flexibility to the types of data that it could hold.
via Wikipedia infobox
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
Excerpt from the source-code README · 7,162 chars · not written by Vinony
via Wikidata · CC0
via Wikidata sitelinks · CC0
Discovered by embedding cosine similarity (sentence-transformers MiniLM, 384-dim).