A Turing Complete Social Protocol

# A Turing Complete Social Protocol Farcaster and Bitcoin are very different networks but share a parochial approach to problem-solving. Bitcoin lets users store and move money without a trusted third party, while Farcaster does the same for text. Describing Farcaster as a **decentralized**, **public**, and **text-centric** social network would be accurate. Many apps have a "twitter-like" feel, with a text feed generated from a set of "follow" relationships. Developers are starting to push the limits of the current design, with apps focussed on image and video sharing, physical presence, and on-chain ownership. People want Farcaster to act more like Ethereum and less like Bitcoin, allowing more degrees of freedom and creativity. Could Farcaster become a "Turing-complete" protocol allowing different social networks to be built? Or is a unique architecture needed for each? ## Achieving Completeness Farcaster already has essential building blocks like decentralized identity, text storage, and graph relationships. But building diverse networks like Facebook, LinkedIn, YouTube, or Whatsapp requires a few more elements: - **Flexible schemas** so that devs can introduce new content and metadata types without a protocol upgrade (e.g., polls) - **Context separation** so that users can keep identities, graphs, and data segregated across networks. - **Long-term storage** so that users don't have to discard older data which is valuable on some networks. - **Private casting** so that developers can design private networks like Snapchat, Facebook, or Whatsapp. It's vital that these features can be grafted on progressively in a backward-compatible way. Farcaster already has a community of users, developers, and applications that must be brought along for the ride. ## Flexible Schemas Data on the Farcaster network is limited to pre-defined protocol schemas. For example, users can "react" to casts in one of two ways: liking or recasting. Introducing a third type would require a protocol upgrade which is a slow process. A flexible reaction type where developers have freedom over the type allows the creation of ad-hoc features like polls. Users could respond with a reaction of type 1, 2 or 3, signaling votes. Developers can standardize using an ERC-like system to create new social primitives without protocol changes. In particular, Farcaster should extend UserData to support different fields, Reactions to support many types and targets, and Verifications to extend to arbitrary signatures and proof systems. ## Context Separation A Farcaster user's identity, content, and social graphs are global in scope. It's assumed that users want to port identities across networks, which isn't always true. Users might share identities and posts between LinkedIn and Twitter but want separation between Twitter and Snapchat. Ideally, Farcaster would allow the following: - **Message tagging**, so that users can target content or graphs to specific networks. - **Multi-identity wallets**, so that users can store different fids and fnames in unrelated on-chain addresses for privacy. - **Parallel namespaces**, so that users can have different names across networks without saturating a single namespace. ## Long Term Storage Users can only store limited data on Farcaster, so Hubs remain small and decentralized. Older messages expire and are pruned as newer ones are created, which is tolerable for real-time networks like Twitter. But this prohibits the creation of long-lived content networks like YouTube, where older content may be just as, if not more, valuable than newer content. Storage can never be unbounded, but there are a few ideas that can dramatically increase the amount of storage available for valuable content on the network: - **Sharding**, or separating storage across nodes so that the overall capacity increases without becoming more centralized. - **Metered Storage**, so that users can pay for more storage on the network. - **Archiving**, where older data is ferried into trustable, long-term storage on other networks periodically. Another problem is that apps will compete for storage within a user's limits. Farcaster would need to offer techniques where a user's actions on one network might evict data produced on another. This includes: - **Sandboxing**, where each app has its own storage limit per user that it cannot exceed. - **Storage management**, where apps expose interfaces to prune data when exceeded. ## Private Casting Messages or "casts" on Farcaster are public, and there is no notion of a private, encrypted message. Friend-based social networks like Facebook, Whatsapp, or Snapchat can only be built with privacy guarantees. Building such networks would require a messaging system that has: - **E2E encryption**, with some guarantees around forward secrecy and break-in recovery - **Efficient Group Encryption**, to target a large, evolving audience of 100+ people. - **Decentralized delivery**, so that hubs can ferry messages instead of centralized servers. - **Privacy**, so that no one can reverse engineer who a user is talking to. The hardest bit is that these guarantees must hold in the face of untrustworthy clients. This tall order may push up against the boundaries of current state-of-the-art cryptography. ## Conclusion Evolving the network to a state where it is Turing complete is likely a multi-year or never-ending journey since the needs of social networks will evolve over time. But significant strides can be made by focusing on the low-hanging kiwis first: adding flexible schemas and network separators. Once that's exhausted, we can concentrate on the more complex problems of scaling storage and private messaging.