Abstract

The rise of global social network giants empowers the centralized tech cartels to misuse user data, infringing user privacy and imposing censorship. Investigated by Cambridge Analytica, Facebook collected social graphs and personal profiles from millions of users without their consent to facilitate political advertising, inappropriately profiting from personal data. The current landscape of Web 2.0 centralized social network has deviated from the principle of the World Wide Web to enable the decentralization of information on a large scale.

As the solution, we desire a decentralized, censorship-free, and self-sovereign social network, which exactly aligns with the thesis of the Web 3.0 revolution. At the dawn of Web 3.0, CyberConnect is here to build a decentralized social graph protocol that serves Web3 social networks and the metaverse. Our mission is to return the ownership and utilities of social graph data back to users while providing an infrastructure for all Web3.0 developers to integrate and build upon.

Roadmap of Web 3.0

The breakthrough innovation of the Ethereum blockchain enables smart contract execution in a decentralized way, opening the chapter of decentralized applications interacting with digital assets. We’ve seen the prosperity of the DeFi summer and the NFT summer. Numerous Dapps have committed to facilitate the trading of digital assets.

On the other hand, we are excited to see the increasing popularity of decentralized UGC platforms like mirror.xyz and blockchain-based games such as Axie Infinity. We believe the next major step on the roadmap of Web 3.0 will be the bloom of decentralized social networks and blockchain-based Metaverse. A decentralized social graph protocol will be an indispensable part of it.

Lack of a decentralized social graph protocol, current games, and social applications store users’ connection data in a centralized way. Users have to go through the process of building connections repeatedly whenever log in to a new application. Imagine how amazing it could be when you log in to Decentraland, Dark Forest, or even Opensea and you can immediately know your friends from your address book who are also using this app. With CyberConnect, users can roam around different Dapps and games on Web 3.0 with their digital assets, on-chain identities, and social graphs without giving up control to any centralized party.

CyberConnect Protocol

Protocol overview

We propose CyberConnect, a decentralized protocol for constructing the blockchain address-based social graphs. The CyberConnect Protocol will have the following features:

• Publicly accessible: the decentralized social graph data will be publicly accessible for all Dapps as an add-on feature for developers to leverage users’ connections to grow beyond their existing user base.

• Self-sovereign: while the social graph data are open to all, only users have full control over their own social graphs, i.e., adding, deleting, and updating the connections.

• Blockchain-agnostic: instead of tying to a single blockchain, the protocol is created for a multi-blockchain ecosystem. The blockchain-agnostic feature will support connections from all blockchains.

• Decentralized governance: Inspired by Ethereum’s vision, we will commit to the ideals of security, permissionless, and decentralized governance. The long-term development of the protocol will be subject to decentralized governance.

• Token-incentivized: in order to support the long-term development of the CyberConnect Protocol, we introduce a token-incentivized model in the beginning stage to fairly reward all contributors who help bootstrap the social graph.

Options for privacy-preserving features: we know some users care about their connection data more than others do. We are actively researching the technical solutions for enabling privacy-preserving features in the future.

Storage

At the heart of CyberConnect is a tamper-proof data structure that efficiently facilitates the creation, update, query, and verification of user-centric data.

Each piece of user-centric data is represented as a data stream where the update is only allowed by the data owner. Each update to the data is appended to the data stream in the form of an append-only commit log and the resulting data structure becomes a hash-linked data structure called a Merkle DAG. To provide data authenticity, we utilize the dag-jose IPLD codec so that each piece of data, whether the creation file or the individual updates is signed and optionally encrypted by the data owner. Before appending a new commit to the data stream, an authorization check is performed to ensure that only the data owner could append new updates. After the custom IPLD encoding, the data is safely stored in IPFS to provide content addressed lookup and data integrity. By this design, each user's social graph is only modifiable by the user, readable to applications with proper decryption permission given by the user, and verifiable by the signature attached.

We partner with Ceramic for our first release based on their implementation of such a mutable data stream storage system on top of IPFS. Further performance improvement will be achieved by writing a heavy data model.

Data availability among nodes is achieved through libp2p pubsub so that as long as one node subscribed to the pubsub topic has the needed commit log, data will be available for query among all the nodes.

Long-term data retention is guaranteed through Ceramic’s blockchain anchoring and our custom data pinning service.

Authentication and Authorization

To fully give back ownership of user data, we have to first sort out authentication and authorization. The authentication of a user simply means that they are who they claim they are and is easily achieved by a signature using a user’s private key. The authorization of user data means that only the user has the access to write their own data and no other central party like Facebook could modify anyone’s data. Authorization is done with the help of pre-commit checks and dag-jose IPLD encoding to ensure correct signing after commit.

Given these two requirements on authentication and authorization, we designed a safe keychain scheme for Authentication and Authorization based on a public-key system (asymmetric key pairs). Firstly, users should not sign any non-transactional data with their blockchain private key. Signing with a blockchain private key provides an extra hurdle to the user experience and broadens the attack surface. Thus, we need to generate key pairs with ed25519 curve from the entropy of a blockchain wallet signature on the client-side. The private key is generated inside a protected iframe and exposed to applications only through rpc to prevent XSS attacks.

The key pairs are then later encrypted with the user’s existing keychain private key (blockchain private key if keychain private key not existent) and stored in the specific data stream for a keychain. The keychain data stream is authorized and protected through a key rotation scheme combined with blockchain anchoring to resolve conflicts.

User-centric user tables

IPFS storage has a common centralization concern where CIDs are stored in a centralized server. This raises the problem of data authenticity where a central server could swap out the real user-created data with fake ones by changing the CID. As mentioned above, we do enforce data signature with dag-jose codec so that data authenticity is guaranteed.

To lookup a certain user’s social graph, we first need to lookup the keychain of the user through their blockchain address. Then we could look up the user table through the keychain public key. In contrast to an application-centric design in web2, where each application stores some information about the user and information like name and avatar are duplicated across applications, in our design, a single user table for each user contains all the information needed and could be used across all applications. By putting all the social graph information inside one user table, only that user has the permission to update any data involved and only the parties that have been given the decryption key could read the data inside if encrypted.

Data indexer

Similar to how thegraph indexes transactional data on Ethereum, all the social graph data on top of CyberConnect welcome data indexers. On CyberConnect, social graph data is stored as unilateral connections. For example, if Alice follows Bob, Alice would add Bob to her own following list. However, Alice could not modify Bob's follower list due to limited access. Thus, we only store the following list inside the user table but not a follower list. Any indexer could easily retrieve such following list and recover a counter-party follower list and provide such data for easier application queries. We would first rollout an indexer for the aforementioned follower list use case (stored in computed index) and welcome other interesting data indexing opportunities by the community. Any user with some technical skills could verify the validity of a computed index and a more sophisticated system involving slashing could be developed in the future.

Node

A node must provide the following functionalities to maintain such a decentralized social graph. A Ceramic node including a custom IPFS daemon with dag-jose IPLD encoding. This handles all the keychain authenticated data stream creation and update. It also maintains the desired data availability through libp2p and IPFS data pinning service, and stream data consensus with blockchain anchoring. An RPC endpoint that exposes the data stream. A data indexer that provides reverse lookups and data aggregation. To generate a reverse “follower list” based on unidirectional following connection.

Architecture (v1)

Use Cases

We conceptualize the decentralized social graph as a collection of unilateral paths among different blockchain addresses. This simple structure is flexible and can potentially support many interesting Web 3.0 use cases.

Decentralized social media applications can integrate the open social graph powered by the CyberConnect Protocol to bootstrap the Web 3.0 versions of Medium, LinkedIn, and Twitter.

Web 3.0 based IM (instant messaging) applications can leverage the bidirectional sub-graph(meaning two users followed each other) as the contact list to grow the user base.

Blockchain games can import the social graph to enhance their social features. Players will be able to communicate and play with their on-chain friends effortlessly. Since users are collaboratively contributing to the decentralized social graph, the increasing adoption of the social graph results in a stronger network effect. A new connection created in one Dapp will benefit all Dapps utilizing the CyberConnect Protocol.

We introduce the concept of a Web 3.0 based IM application we are specifically interested in below: CyberChat. As the showcase of the utilities of the CyberConnect Protocol, CyberChat is expected to be the exemplar of a matrix of Web 3.0 applications based on CyberConnect in the future.

CyberChat

Enabling messaging between blockchain addresses and allowing users to socialize with their crypto assets natively will be the next step for completing the social ecosystem on Web 3.0. CyberChat is a trustless Web3.0 chatting app for all blockchain users. More information about Cyberchat will be available soon.

Future possibilities: DIDs

Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. It’s a standard created by W3C for users to identify themselves without centralized registries, identify providers and certificate authorities.

In the future, we can use DID as a globally unique identifier for each web3 user and each DID contains private-public key pair for a user to interact with services and data safely. Each DID is also linked to one or multiple blockchain addresses and those addresses could even be on different blockchains.

There are several benefits with this DID approach. Users are uniquely identified without a central authority and user data’s integrity is preserved by DID signature. Users could link different blockchain addresses to one DID, which suits the ever growing Layer1 blockchain landscape. Users will not use their blockchain private key to sign any non-transactional information like sending a message or updating their avatar.

Each DID represents an abstract, key-agnositic, and blockchain-agnostic interfaces used to uniquely identify entities, sign and encrypt information and delegate access control to services.

Links: