thearchivist.funActivityPub gives the social web a shared delivery language
On 23 January 2018, the World Wide Web Consortium published ActivityPub as a Recommendation. The specification described two related ways for social software to communicate: a client-to-server interface for a person's application and a server-to-server protocol for exchanging activities between independently operated services. Its vocabulary builds on ActivityStreams, so a message can describe actions such as creating an object, following an actor or announcing somebody else's contribution. The important architectural move was to treat social interaction as communication among addressable actors, inboxes and outboxes. A social application no longer needed every participant to have an account in one company's database before messages could travel between them. Different services could implement the same protocol while making their own choices about interface, hosting, moderation and community purpose. That possibility did not mean every feature automatically became interoperable: implementations still had to agree on the objects and behaviors they supported. ActivityPub also makes a useful distinction between a protocol and a social settlement. The specification defines message handling, authentication considerations and delivery behavior; it does not decide which server a community should trust or which speech its moderators should allow. A network can share a transport standard and still contain conflicting policies. For an internet-history archive, this milestone explains why a public post may have several visible locations. The original object, a remote copy and a screenshot are related evidence, but they are not interchangeable records. A careful citation keeps the original address, identifies the publishing account and server, and records the capture time. Federation expands where a conversation can travel; preserving its context still requires deliberate work.
Context and provenance
Read this alongside the later entries about Threads federation and Bluesky's AT Protocol. Both concern movement across services, but their architectures and account models differ. The comparison is useful precisely because the term decentralized does not describe one uniform design. When documenting a community, ask who hosts its records, who controls the client, where moderation decisions occur, and what happens when a participant changes providers. Those questions reveal practical power and dependency more clearly than a platform's marketing label. They also help explain why two people can encounter different versions of the same discussion.
Why it matters
A published interoperability standard made independently hosted social services part of a shared technical conversation.
Sources and evidence
Editorial review: 2026-09-23. New evidence may change this account.