Meta Moves To More Directly Connect To ActivityPub, But Is It Really Open?

Meta is actually making moves to live up to its promise to integrate Threads into the open ActivityPub standard used by a variety of “fediverse” platforms such as Mastodon and Pixelfed. It’s a fundamental boost to the concept of protocols over platforms, but it’s still not entirely clear how “open” Meta is really going to be with Threads.

In the last few months, I’ve been to a few different gatherings that were heavily populated by Meta folks working on Threads where they’ve made it quite clear that they are earnest about embracing the ActivityPub standard, which we noted was an incredibly important step for Meta.

Every Meta product to date has been a closed, proprietary silo. Once you check in, your only way to check out is to leave the platform entirely, meaning you can no longer easily see posts from others on the platform or communicate with them as easily either. Embracing ActivityPub, a standardized decentralized protocol that allows for a more “federated” experience, was a big step towards a more protocolized world.

It was something Meta didn’t have to do, but it’s a move that could impact the wider thinking about how social media platforms operate and who actually controls the data.

Now, some users who rely on ActivityPub (mostly on Mastodon, but many other services as well) have been quite nervous about Meta’s embrace of ActivityPub, as there’s a legitimate fear of it overwhelming the system or causing problems. Or, if Meta wanted to be nefarious, the infamous Microsoft-endorsed strategy of embrace, extend, extinguish, was always lurking.

And while that’s always possible, there are a few reasons to be moderately optimistic. One reason is just that the folks at Meta working on this seem quite aware of that fear and are doing everything they can to minimize the risks and to be good neighbors in the wider fediverse. And while there is still some fear that maybe they only send out the nice, earnest believers to the meetings, while the real bastards are waiting behind the scenes, even if Meta did try to destroy ActivityPub, the nature of it being an open standard limits how much damage it could really do.

Some instances are already blocking Threads, and if Meta becomes too much of a problem, then others would likely do so as well.

And while some had predicted that Meta would never actually embrace Threads, it keeps turning on more functionality, bit by bit. The latest functionality is that users on Threads can now see likes and replies from the wider Fediverse. Before this, users on ActivityPub-based systems like Mastodon could follow Threads users who opted-in to connect to the Fediverse, but the users on Threads would not see any “likes” or replies. And now that’s changing.

This follows what Meta folks have suggested over the last few months of rolling out ActivityPub integration slowly and carefully, to make sure they really don’t overwhelm or break things.

I think all of this is good so far, and it’s good to see a major platform embracing more decentralized social media. But there are still some concerns.

Just a few weeks ago, in a conversation with some researchers about decentralized social media, I pointed out the one thing I’d really like to see, but hadn’t yet, from the Meta side: third-party clients and additional services built on top of Meta. But, to date, I hadn’t seen any.

And, a few days later, I learned one reason why. Over on Bluesky David Thiel pointed out that, last fall, Meta had big-time lawyers at Perkins Coie send cease and desist letters to developers building a Threads API client that would have enabled more third-party apps and services. And, indeed, you can see that threat letter on the unofficial Threads API Github.

There are a few ways to think about this. First, given how much shit that Meta got into (including massive fines) for the whole Cambridge Analytica mess, you can see why they might want to more tightly control any API access. And sending threat letters to unofficial API tools is one way to do that.

Also, one could argue that thanks to the increasing ActivityPub integration, those who want to build can just build something for ActivityPub and get access to any Threads content from users on Threads who turn on ActivityPub integration. So, arguably, the existing ActivityPub ecosystem can act as a third party to Threads.

But, even as Threads expands its ActivityPub integration, that solution is still quite limited.

So while it’s nice to see Threads really doing more to integrate with ActivityPub, it seems like its lack of true openness still suggests an inherently closed and centralized system, rather than a truly decentralized one.