Publishing to the Open Social Web with Ghost (ActivityPub Explained)

The modern internet is shifting back toward open, decentralized protocols where publishers retain control over distribution and audience relationships. Ghost’s Social Web feature brings this vision to life by integrating the ActivityPub protocol into its core publishing platform. In this post, we’ll unpack what this means, how it works at a technical level, and how Ghost implements ActivityPub to extend your content beyond your own site.

This article uses information from ghost.org

What Is the Social Web?

The “Social Web” in Ghost refers to the ability to federate content across platforms using ActivityPub — an open, decentralized social networking protocol standardized by the W3C. While classic social media (e.g., X, Facebook) locks audiences behind proprietary APIs and algorithms, ActivityPub enables interoperability between independent services. It works similarly to email: systems speak a shared protocol so users can interact across different software. (ghost.org)

At the core of ActivityPub are three concepts:

• Actors: Entities such as users or sites that can send/receive activities.
• Activities: Events like Create, Like, Follow.
• Objects: Content items like notes or posts.
  ActivityPub leverages JSON-LD and the ActivityStreams 2.0 vocabulary for structured, linked data. (Wikipedia)

Ghost’s Social Web adds ActivityPub support so that your Ghost publication can operate as an Actor on the federated web, exposing both long-form articles and short-form interactions to other compliant services. (ghost.org)

How Ghost Implements ActivityPub

Ghost’s integration is built around a few key technical components:

1. Federated Identity Using Handles

Each Ghost site gets a federated identity in the form of a handle like:

@index@yoursite.com

This site for example is federated as

@sascha@corti.com

This functions similarly to an email address in ActivityPub: it uniquely identifies your publication across the fediverse. This handle resolves to a federated profile containing the Actor’s inbox and outbox URLs — essentially the endpoints other services use to send and receive ActivityPub messages. (ghost.org)

2. Automatic Publishing via ActivityPub

When you publish a new post in Ghost, the system generates ActivityPub Create activities for that content. These activities are then sent to followers’ inboxes on other ActivityPub servers (e.g., Mastodon, Pixelfed) so remote clients can ingest your content in their local feeds. (ghost.org)

This happens without manual action from the author: Ghost emits the necessary ActivityPub JSON-LD and handles serialization and delivery behind the scenes.

3. Inbox/Outbox Model

ActivityPub uses an Inbox/Outbox pattern:

• Outbox: Ghost writes outbound activities (new posts, replies, likes).
• Inbox: Ghost receives inbound activities (follows, replies, likes) from remote servers.

When another server wants to follow your Ghost account, it sends a Follow activity to your Ghost site’s inbox. Ghost stores and interprets this, and the relationship is reflected in the activity streams. (Wikipedia)

4. Built-In Social Web Reader

Ghost now includes a social web reader in the admin UI, which acts like an email inbox for subscribed feeds:

• Reader: Displays long-form content from followed Actors.
• Notes: Shows short-form messages (analogous to microblog posts).
• Interactions: You can Like, Reply, and Repost directly within Ghost, generating appropriate ActivityPub activities and delivering them back into the federated network. (ghost.org)

This reader abstracts ActivityPub activity handling so site operators don’t need to deal with raw JSON messages.

Protocol Workings Under the Hood

Unlike traditional REST APIs, ActivityPub requires server-to-server federation using HTTP POSTs between known inbox URLs. Ghost’s implementation relies on an external ActivityPub server — typically Fedify — which handles:

• Federation logic
• Message queueing
• Inbox/outbox delivery
• Subscription management

Ghost then connects to that server to expose your site’s ActivityPub endpoints. (GitHub)

This separation lets Ghost stay focused on content management while leveraging a dedicated engine optimized for scalable federation. Administrators can choose Ghost’s managed ActivityPub server or self-host their own for more control and higher quotas. (Ghost Forum)

Compatibility & Rough Edges

ActivityPub support in Ghost is currently labeled beta, and not all features or integrations are fully mature. Some practical considerations:

• Platform differences: Compatibility varies across federated platforms. Mastodon generally works well; others like WordPress depend on plugins. (ghost.org)
• Feature gaps: Not all ActivityPub features (e.g., media attachments on some platforms) are fully supported yet. (ghost.org)
• Latency: Federation delivery isn’t instant; it depends on remote server responsiveness.

What This Enables for Publishers

When fully enabled, Ghost’s Social Web integration lets you:

• Reach federated users without requiring them to visit your website.
• Gain followers across a decentralized network of ActivityPub-compatible services.
• Engage with audience interactions (likes, replies, reposts) in a protocol-native, open standard.
• Integrate long-form and short-form workflows — your articles and notes exist on the web under your domain and across the fediverse. (ghost.org)

This architecture fundamentally shifts how content is distributed: no longer locked into siloed networks, your publication participates in a broader, open social graph. (ghost.org)

Conclusion

Ghost’s adoption of ActivityPub represents a major step toward distributed publishing. By exposing Ghost publications as federated Actors on the open social web, authors gain direct access to audiences across the fediverse while retaining control over their content and identity. The implementation — combining Ghost’s CMS with an ActivityPub server — abstracts away most of the protocol complexity, letting editors focus on writing while still engaging in decentralized social networking.

For technical teams and developers, this opens opportunities to build tooling, analytics, and custom integrations on top of federated content streams — all using a standardized, open protocol. (Wikipedia)