Exploring the Future of Web3 Social (Part 1) From 0 to 1 – Achieving Cold Start of Applications with Social Graphs.

Web3 Social Future (Part 1) - Achieving Cold Start of Applications with Social Graphs

Author: LianGuaiUL VERADITTAKIT, Partner at LianGuaintera Capital; Translation: Deep Tide TechFlow

This article is the first in a series of decentralized social articles written by LianGuaiUL, a partner at LianGuaintera.

This series explores how current technologies and trends address a range of issues in decentralized social networks, providing specific explanations and explorations for each problem.

In 2017, a group of researchers from the MIT Media Lab claimed in Wired magazine that decentralized social networks would “never succeed.” In their article, they listed three impossible challenges:

• Enterprise Blueprint BC Technology Group (0863) approved to provide digital currency trading services to retail investors.
• Interpreting the Current Situation of Velodrome V2 Upgrade Record High Revenue, but Token Value Doesn’t Match the Increase in Issuance
• Research Report Arbitrum

1. The problem of attracting (and retaining) users from scratch

2. The problem of handling user personal information

3. The problem of user-oriented advertising

They believed that in all three cases, existing tech giants such as Facebook, Twitter, and Google, due to their extensive economies of scale, left no room for any significant competition.

Fast forward to the present, what was once deemed “impossible” seems less out of reach, and we appear to be at the dawn of a transformation in the concept of social media networks. In this three-part series (this being the first part), we will explore how new ideas in decentralized social (DeSo) address these “age-old” problems, including:

1. Using an open social layer to solve the cold start problem

2. Using proof of personhood and cryptographic technologies to address user identity issues

3. Using token economics and incentive mechanisms to solve revenue problems

Social Graphs and the Cold Start Problem

Social media platforms always face the cold start problem: attracting and engaging users without an existing user base or network effects. Traditionally, emerging social media startups like Snapchat, Clubhouse, or more recently Threads, have attempted to overcome this problem through aggressive marketing and pure marketing capabilities. By capturing everyone’s attention at the right moment, whether through novel user experience design, media headlines, or FOMO, they launch large-scale registration blitzes, creating user barriers on the platform almost instantly. For example, Threads successfully attracted 100 million users in just 5 days.

However, these successful marketing campaigns often face a crisis: how to retain all these users and continue generating new content (and profits)? This was the problem faced by Clubhouse before, and it is the problem currently faced by Threads. As these apps decline, the profitable user social graphs and profiles built by these platforms also disappear, requiring future aspiring social media networks to repeat the challenging marketing strategies to restart their networks.

The fundamental problem behind all of this is that in Web2 social networks, the social graph (annotating relationships between users) is closely intertwined with the social applications themselves (such as Facebook, Twitter, or Instagram). These two aspects are symbiotic: the novelty of the application drives the development of the social graph, and the social graph, in turn, becomes a major barrier for social media applications. Despite various issues, the reason users don’t leave Facebook, Twitter, and Instagram is simple: all of our friends are on them.

But what if we separate the social graph from social applications? Even if Clubhouse (or Threads) disappears, we can still use the social graph created on them to easily launch another social application. This is Web3’s response to the cold start problem.

Using public chains as open social graphs

In a sense, public blockchains like Ethereum itself are social graphs. If I look up an ENS domain or a person’s wallet address on Etherscan, I can see their on-chain social profile: what assets they hold, who they transact with, and infer which communities they belong to.

This on-chain social profile seems like a natural starting point for a new decentralized social network, and in fact, some companies seem to be exploring this path.

For example, Debank converts the hexadecimal dump on Etherscan into readable portfolios or “profiles,” and provides the ability to send messages to these different individuals, thus utilizing on-chain data to launch a messaging-style social network. 0xPPL is also taking a similar approach, attempting to build a Twitter-style social network using on-chain user profiles. This general strategy of making raw transaction data readable and interpretable to “ordinary” users, using advanced large-scale language models like GPT-4, has been accelerating. For example, it is said that Cymbal uses GPT to generate conversational summaries of transactions and trends to create a hybrid of data resources, news sources, and future social networks.

Building native social graph protocols

Simply relying on public blockchain data (such as Ethereum) poses a problem because this data is not rich enough for social applications. Because public blockchains were primarily built for financial applications, not social applications, the data natively collected on-chain, such as transaction history, account balances, and token data, may not be the most useful for social networks.

Unlike using native on-chain data as the social graph, one idea is to build a new, dedicated social graph protocol on top of the public blockchain. For example, Lens Protocol leverages a key observation that there are common factors of social interaction in social applications, which they abstract into different on-chain behaviors such as “posting,” “commenting,” and “mirroring” (i.e., sharing or reposting).

Farcaster also has similar abstractions in its social graph, such as “cast” (publish), “reactions” (likes), and “amp” functionality, where users can recommend other users worth following. The main difference between Farcaster and Lens lies in their technical implementations – Lens puts all content on the Polygon blockchain, while Farcaster places its ID registry on Ethereum itself and runs its social graph in the form of a Delta graph on L2.

Another notable social graph protocol is Cyberconnect, which focuses more on link aggregation (including on-chain and off-chain sources) through its link3 mechanism and focuses on events and fan clubs as initial use cases.

For these social graph protocols, the key is that they don’t necessarily build top-level social applications like Twitter, Facebook, or Instagram. Instead, they provide an open social graph layer (essentially an SDK) for building and extending these top-level applications. As mentioned earlier, the core advantage of doing this is that even if a previously successful social application disappears (similar to Clubhouse), the generated social graph can still be used by other developers. Therefore, it only takes one marketing campaign or a successful application to launch the entire ecosystem.

Designing Decentralized Social Media from Scratch

The third strategy is to build a decentralized solution from scratch. The premise is that social media applications are the cornerstone of our digital experience, so there is a need for a dedicated blockchain (or other decentralized) solution that localizes the basic operations of social media applications, rather than relying on protocols built on infrastructure initially designed to support financial use cases. In short, we need a “social media application chain”.

One of the most notable projects in this strategy is DeSo, which is building an L1 blockchain focused on social applications. Unlike other mainstream public blockchains that focus on “transactions per second,” DeSo aims to optimize “posts per second” as well as the communication and storage needs of social applications. General-purpose blockchains like Ethereum may not necessarily optimize for this. On top of this L1 blockchain, DeSo plans to build various social applications, including long-form content (like Substack), short-form content (like Twitter), and Reddit-like applications.

Other decentralized social media platforms, such as Bluesky and Mastodon, can also roughly follow this strategy of designing decentralized social media from scratch. Strictly speaking, they are not blockchain-based solutions but rely on server systems to ensure sufficient decentralization of posts. For example, Mastodon uses a system similar to email, where users can choose between different service providers (like Gmail, Hotmail, or iCloud). Just as an organization can set up and customize its own mail server, each “instance” on Mastodon is a self-managed and customizable community. On the other hand, Bluesky is an application developed based on the open-source AT protocol, which is essentially an open social graph with APIs for “following,” “liking,” “publishing,” etc., optimized for social media platforms like Twitter.

The commonality between DeSo, Mastodon, Bluesky, and other projects lies in their rejection of the existing public blockchain designs (represented by EVM) for social networks. Although this approach undoubtedly provides these projects with the ability to have more fine-grained control over design decisions and user experiences, it also severs potential connections and cross-impacts with mature elements in DeFi, existing NFT communities, and the Web3 ecosystem. Additionally, it remains to be seen to what extent these solutions are “decentralized,” especially in environments where their decentralization is not guaranteed by public blockchains. Will these solutions eventually bundle social graphs with social applications like existing social networks, or will they fully decentralize the social graph layer and attract various applications and development teams? This is a key question for the future of Web3 social networks.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!