A New Kind of Interoperability for Threads

Threads is taking its first steps into the fediverse. In a beta release rolling out in a few countries, users who are at least 18 years old and have public profiles can opt to share their posts with other servers that support the ActivityPub protocol. This means people on those external servers will be able to follow Threads profiles, as well as view, like, reply to, and repost content from them.

The move marks Meta's first foray into open social networking. For the engineering team, it introduces a host of new challenges around interoperability that differ significantly from building a standalone platform.

Understanding the Fediverse and ActivityPub

The fediverse can be understood using the email analogy. Just as a Gmail user can exchange messages with a Yahoo user because both services support the same standards, the fediverse allows people on different social platforms to connect if they all adhere to a common protocol. Unlike email, however, conversations and profiles in this space are public and can be distributed across many servers.

Threads relies on ActivityPub, a decentralized social networking protocol established by the World Wide Web Consortium (W3C). This protocol is fundamentally a server-to-server interface that enables distinct servers to communicate, deliver content, and share activities. By building on this standard, Threads is positioned to eventually allow its users to interact with people on platforms like Mastodon without requiring separate accounts on those services.

A key aspect of this decentralized model is that each server can set its own rules for community standards and content moderation. This gives users the flexibility to select online spaces that match their values, an approach that supporters believe promotes a more diverse and competitive social media ecosystem.

Federating Content in the Beta

When a Threads user opts into sharing, their public posts become visible on other ActivityPub-compliant servers. Within the Threads app, these users will see aggregated like counts from the fediverse. Remote users who follow these profiles can interact with the content in standard ways, provided their own server permits those actions.

There are limitations in this initial phase. Federated Threads users will not be able to see who liked their posts or view replies coming from other servers while staying in the Threads app; they would need to visit the external server directly to read those replies. Certain content is not federated at all:

  • Posts where replies are restricted.
  • Replies made to profiles that have not enabled federation.
  • Posts that include polls.
  • Reposts of content from non-federated profiles.

For posts containing links, if the link text isn't already within the post body, a link attachment is automatically appended to the end of the post for external display.

Handling Quote Posts

Federating features that exist across the fediverse isn't always straightforward. Quote posts are a prominent example because ActivityPub lacks a formal specification for them. This has led to various servers adopting their own informal methods to handle the feature or dropping support altogether.

Among the existing community proposals is FEP-e232, which suggests a way to represent text-based links to posts similarly to how mentions work. Another approach involves a quoteURL property within ActivityPub. Misskey, however, submitted its own solution with the _misskey_quote property, which is built upon FEP-e232. Many servers also resort to adding plain syntax like RE:<quoted post URL> to the post content for broader compatibility.

After reviewing community options, Threads is implementing support for both FEP-e232 and _misskey_quote. The choice of the latter was made partly due to its clear naming, which denotes that it is not an official ActivityPub method, and because it is already supported by servers like Misskey and Firefish. In this system, a quote post from Threads contains a permalink URL to the original post alongside a structured representation of it. This allows external platforms to render the quote post contextually. If the quoted post comes from a non-federated profile, only the permalink is sent, without the structured data.

Mixing Federated and Private Audiences

Because not every Threads user will turn on fediverse sharing, the development team had to manage interactions between users who are federated and those who are not. Attempting to broadcast every reply or repost indiscriminately isn't viable. The current design ensures a federated interaction—like a reply to another federated user's post—is shared. However, to help users understand the implications of their choices, the app requires specific UI/UX notices regarding what will happen to their content when they post, given the potential mixed audiences and feature limitations.

A Phased Roadmap to Full Interoperability

The company is using a phased strategy to ensure a safe and stable transition into the fediverse. Right now, the flow is one-way out of Threads. Later, content is expected to flow back in, allowing Threads users to view replies from external servers and follow individuals on those other platforms directly. The long-term goal is for Threads profiles to display a single, unified follower count that aggregates followers from both Threads and the fediverse.

As of now, there are no specific dates for future milestones. The team notes that building federated features safely is a delicate process, particularly when addressing the differences in how various servers implement features. The stated intention is to continue collaborating with the broader fediverse developer community as Threads works toward a fully interoperable experience.