- Threads has entered the fediverse! As part of our beta experience, now available in a few countries, Threads users aged 18+ with public profiles can now choose to share their Threads posts to other ActivityPub-compliant servers.
- People on those servers can now follow federated Threads profiles and see, like, reply to, and repost posts from the fediverse.
- We’re sharing how we’re continuing to integrate Threads with the fediverse, the technical challenges, the solutions we’ve come up with along the way, and what’s next as we move toward making Threads fully interoperable.
Threads’ initial launch came together in only a few short months. A nimble team of engineers, leveraging Meta’s existing scalable infrastructure, was able to make Threads Meta’s most successful app launch of all time.
Now, we’re integrating Threads with the fediverse. With our beta experience, now available in a few countries, including the US, Threads users aged 18+ with public profiles can now choose to federate their profiles – allowing them to share their Threads posts to other ActivityPub-compliant servers, and enabling people on those servers to follow them, and like, reply to, and repost their posts.
Building a federated platform – Meta’s first app for open social networking – has meant new engineering challenges and opportunities. Designing for the fediverse comes with unique interoperability considerations and hurdles to overcome on the server side.
What is the fediverse?
When we set out to build Threads our goal was always to build a decentralized social networking app within the fediverse, where federated networking gives people greater control over their online identity and the content they see, regardless of their chosen platform.
One way to think about the fediverse is to compare it to email. You can send an email from a Gmail account to a Yahoo account, for example, because those services support the same protocols. Similarly, in the fediverse you can connect with people who use different social networking services that are built on the same protocol, removing the silos that confine people and their followers to any single platform. But unlike email, your fediverse conversations and profile are public and can be shared across servers.
Building Threads on an open social networking protocol gives people more freedom and choice in the online communities they inhabit. Every fediverse server can set its own community standards and content moderation policies, meaning people have the freedom to choose spaces that align with their values.
We believe this decentralized approach, similar to the protocols governing email and the web itself, will play an important role in the future of online platforms. The fediverse promotes innovation and competition by fostering a more diverse and vibrant ecosystem of social media platforms that can easily connect with a wider audience.
What is ActivityPub?
Threads leverages ActivityPub – a decentralized, open social networking protocol built by the World Wide Web Consortium(W3C) – that is premised on a straightforward, fundamental idea: creating a social networking structure based on open protocols that allow people to communicate and network with each other regardless of the server they choose.
ActivityPub acts as a server-to-server protocol where the API allows decentralized servers to communicate with one another to deliver content and activities.
The protocol plays a key role in allowing Threads to be interoperable with other servers that also use it. Eventually, people on Threads will be able to interact with people on platforms like Mastodon and WordPress without having to sign up for accounts on those apps.
The current state of fediverse integration in Threads
With our beta experience, Threads users aged 18+ with public profiles can now choose to enable sharing to the fediverse. If they do, they’ll be able to publish posts on Threads that will be viewable on other ActivityPub-compliant servers. Threads users will also be able to see aggregated like counts on their posts from other fediverse servers directly from the Threads app. If people on other fediverse servers follow federated Threads profiles they’ll be able to see, reply to, and repost Threads posts (if their server allows it).
What types of content are federated?
In this initial phase federated Threads users will not be able to see who liked their posts or any replies from people in the fediverse on Threads. For now, people who want to see replies on their posts on other fediverse servers will have to visit those servers directly.
Certain types of posts and content are also not federated, including:
- Posts with restricted replies.
- Replies to non-federated posts.
- Post with polls (until future updates).
- Reposts of non-federated posts.
For posts that contain links, a link attachment will be appended as a link at the end of the post if it is not already included in the post.
Building more federated features for Threads
More federated features for Threads will come once we have addressed other technical hurdles in a way that we feel is safest and offers the best possible user experience. Within all of this, it’s also important to us that, as we build these solutions, we do so alongside the open and decentralized fediverse developer community.
As we federate new features in Threads, we have to look at how to address the disparity in the availability and implementation of these features across servers.
Federating quote posts
Take quote posts as an example. They’re a popular feature across all social media, but ActivityPub does not have a formal specification for how to handle them yet. Thus, fediverse servers have come up with their own methods of integrating and handling quote posts. Some servers allow for creating and viewing quote posts; others don’t support the function at all.
There are a handful of unofficial methods for handling quote posts in ActivityPub. One fediverse enhancement proposal (FEP), FEP-e232, proposes a way to represent inline quotes and other text-based links to ActivityPub in a manner similar to mentions on other social media platforms. Another method would be to use the quoteURL property within ActivityPub, which would assign posts an ID that could then be pulled into other posts that want to quote them. Misskey created its own solution with its _misskey_quote property, which builds on FEP-e232.
Many fediverse servers also append extra syntax (RE:<quoted post URL>) to post content to make it compatible with servers that haven’t implemented any of the structured methods for handling quote posts.
After exploring different options pursued by the fediverse community, we chose to implement both FEP-e232 and _misskey_quote to federate quote posts on Threads. As of now, none of these methods are official keys in the ActivityPub namespace. We chose _misskey_quote because its naming makes it clear that it’s not an official ActivityPub method, and because we know that it’s supported by Misskey, Firefish, and potentially other servers that use quote posts.
In our current implementation, if a Threads user creates a quote post from a federated post, the quote post will contain a permalink URL (e.g. “RE: <URL to permalink>“) to the post along with a structured representation of the post. Platforms outside of Threads can display the quote post similar to how it’s displayed on Threads by using the structured representation to fetch the post and display it within the quote post.
If the post being quoted is not federated, the quote post’s content will only contain the permalink URL and not the structured representation.
Federated and non-federated interactions
If a federated Threads user is replying to, quoting, or reposting a post from another federated Threads user it makes perfect sense to federate that reply, quote, or repost (which we do).
However, we had to take a careful look at the complexities that arise since not every Threads user will opt in to turn on sharing to the fediverse. Prioritizing the user experience for both those who federate and those who choose not to is important to us. Which also means federated and non-federated users on Threads should still be able to interact with one another seamlessly.
Unlike other federated platforms, Threads doesn’t simply federate every post. Given that features like replies may or may not be federated, we had to build UI/UX treatments and notices to help people understand what is happening and what to expect when posting.
Our phased approach to the fediverse
We’re taking a phased approach to Threads’ fediverse integration to ensure we can continue to build responsibly and get valuable feedback from our users and the fediverse community.
In the future, we expect content to flow from the fediverse into Threads. Federated Threads users will be able to see and engage with replies to their posts coming from other servers, or follow people on other fediverse servers and engage with their content directly in Threads. Our plan is for fediverse-enabled Threads profiles to ultimately have one consolidated number of followers that combines users that followed them from Threads and users from other servers.
Building a federated social networking app is a complex and delicate process if it is to be done safely. While we don’t have exact dates or details on our milestones just yet, we’re committed to a fully interoperable experience, and we’ll take the time to get this right and grow the fediverse responsibly.
This is another step in our journey to make Threads fully interoperable. We will continue to collaborate with developers and policy makers so that people across services have the opportunity to experience the benefits the fediverse offers via a fully interoperable experience, including reaching new audiences and fostering their community.
