Forking Facebook

TLDR: A work-in-progress in which we describe how developers can adversarially "fork" a social media platform,¹ allowing users to use their identities without relying on the platform itself.

This is not just decentralized social media, but an example of using a decentralized protocol to disrupt the market structures and network effects that encourage centralization.

Facebook and centralization

Facebook, of all the powerful tech companies, might exert the most influence over its users' lives. 2.7 billion people have a Facebook account, 2 billion have Whatsapp, and a billion use Instagram. A small group of people in Menlo Park make decisions that shape how billions of people communicate with their friends and consume information. In short, Facebook represents an incredible concentration of centralized power and potential energy for decentralization.

I'd like to propose a design for forking Facebook. This would allow users to authenticate content with their Facebook identities outside of Facebook servers, without cooperation from Facebook. It would help impose a competitive market structure that would force social media providers to serve users, and it's possible to build on scalable blockchains like Mir, even with billions of users.

A decentralized alternative

Any alternative our social media ecosystem should provide three things. First, it should allow users to bring their existing identities with them. Second, it should allow differentiated product experiences: some users might prefer a client that minimizes engagement, rather than maximizes it, or one with stronger privacy protections. Third, users should be able to switch social media providers without friction.

Simply building a decentralized Facebook that runs on many independent nodes is impractical and doesn't directly address any of these issues. It doesn't allow users to preserve their existing identities, and it doesn't allow a differentiated product experience.

Instead, we can decentralize the authentication layer, using a blockchain to manage user keys and to provide global state. Users can identify a social media provider that hosts their content, and use the chain to exit from that provider at any time.

Privately recoverable accounts

The first component of this design is a privately recoverable account. This consists of a set of keys corresponding to user devices and a recovery condition that allows users to change this set. The recovery condition can be any arbitrary program encoding conditions for social recovery, DKIM signature verification, even a password.

Privately recoverable accounts are handled on a blockchain like Mir. They abstract away key management from the user, and provide a similar user experience to existing centralized services. As keys are accessible from multiple devices, users don't need to manually copy keys or carry specialized hardware to authenticate content. Moreover, on Mir, recovery conditions can remain private, which is critical for security.

As we'll see, blockchains also provide a mechanism for exit, if a user decides to switch social media providers.

Exiting Facebook

A user can map an existing social media account to Mir, without any cooperation or support from the social media platform itself. This is an instance of adversarial interoperability.

We achieve this through a social proof, a concept popularized by Keybase. If Alice wants to link her Facebook identity to a Mir account, she generates a cryptographic proof² that she includes in a public post.

Anyone can access this public post³ and verify that Alice's Facebook identity is linked to a Mir account. If Bob receives a message, or sees a post, he can verify that it was written by Alice by checking a signature against one of Alice's keys in her Mir account.

Interoperability

We have a way to authenticate messages from a Facebook identity outside of a Facebook service. But how will users receive or store content?

This design relies on generic social media providers that perform the same functionality that Facebook does: passing messages, and storing and serving content. The relevant difference is that there is no lock-in, as Alice can simply decide to use a different provider, while maintaining her identity.

Notes