> For the complete documentation index, see [llms.txt](https://chainedx.gitbook.io/chainedx-protocol/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://chainedx.gitbook.io/chainedx-protocol/4.-social-graph.md).
# 4. Social Graph
The Protocol provides for the decentralized creation and management of a global mapping of all users and how they are related. This global mapping is commonly known as a social graph. Relationships are first-order primitives in the protocol, and they represent connections between users in a social graph. The two most common relationship types in social networks are “Friend” and “Follow.” These relationships represent connections between Social Identities, and can be public or private. Public relationships can be seen by anyone, while private relationships allow user control over who can view them.
4.1 Relationship Types
Users, represented by Social Identities, are the vertices in the social graph, and relationships are the edges. These relationships can be directed, such as in a Follow relationship, or undirected, such as in a Friend relationship. Twitter is an example of the directed Follow model. A public Follow relationship is created by the follower, but it does not require the permission of the followed. The reciprocal relationship can also exist, but it is not required. The follower controls both the formation and removal of the relationship. Facebook and LinkedIn are examples of networks that have an undirected Friend model. This requires the permission of both users to form the relationship, but either can remove it. The Protocol uses Follow-based, directed edges in its social graph. The undirected Friend relationship, along with other relationship types, can use this directed approach as a building block for more complex relationship types. Access to encrypted, private posts requires permission from the user being followed in order to obtain the appropriate decryption keys, and closely resembles the process of creating a Friend relationship.
**4.2 Graph Change Events**
The protocol models the creation or removal of a Follow relationship as a Graph Change Event. The sequence of these events represents the current state of the social graph rooted at each Social Identity. The event structure allows some data to be either public or private, even though all events on a public blockchain are by necessity public. A mechanism is also provided for sharing private event data with trusted parties.
Figure 3: Graph Change Events
**4.2.1 Structure**
To create a Follow relationship, the aspiring follower creates a Graph Change Event, with themselves as the Actor, the Social Identity they want to follow as the Object, and follow as
the Action. The Graph Change Event is then published via smart contract invocation on the user’s Social Identity smart contract instance, making it visible on the blockchain. Graph Change Events have four major components2: Type: Whether this is a public or private Graph Change Event. Actor: The Social Identity creating the event. In a public Follow relationship, this would be the follower. Object: The Social Identity that is being linked to the event. In a public Follow relationship, this would be the user being followed or unfollowed. Action: The action being taken. In a public Follow relationship, the options are follow and unfollow. A series of Graph Change Events are depicted in Figure 3, along with the resulting state on the blockchain (notice that the unfollowed friends are no longer present).
**4.2.2 Privacy**
Graph Change Events always have unencrypted Type and Actor values. Graph Change Events of type public also have unencrypted “Object” and “Action” values. Graph Change Events of type private encrypt the values for “Object” and Action. This means that, despite the Graph Change Event being published to the blockchain, a key is required to interpret the encrypted values. A user generates a symmetric encryption key for encrypting the private Graph Change Events data. The user can store this encryption key in their wallet or on chain (see the “Key Storage” section). While private Graph Change Events do not allow outside observers to read who is being followed, it is still possible to see that the Social Identity expressed in the Actor field is actively publishing a particular type of event, which may still convey some level of valuable metadata information to a third party.
**4.2.3 Validation**
Graph Change Events are only partially validated when published to the blockchain. Type and Actor are validated as part of the publishing process. However, since Object and Action may be encrypted and unreadable by the smart contract, they are validated by the consumer of the Graph Change Event message. Private Graph Change Events can be validated only by those who can decrypt the data.
**4.2.4 Sharing**
While public Graph Change Events are fully understandable by everyone, without additional action, only the Actor user has the ability to interpret their private Graph Change Events. Users may wish to share their graph with other users, user agents, or third-party online tools. Sharing is a conceptually simple process, but like many self-sovereign schemes, ceasing sharing is substantially more complicated. To share their list of private Graph Change Events with another party, the user can simply communicate their symmetric key through a secure direct channel. Doing so allows the other party to read the data, but does not allow them to modify it. The key is used for data encryption, but does not allow signing new Graph Change Events from that Actor.5This simple approach, however, is complicated by the need to be able to cease sharing with a third party.
**4.2.5 Cease Sharing**
To stop sharing private Graph Change Events with a third party, the symmetric key used to encrypt data on the Graph Change Event is rotated to a new value. No existing Graph Change Events are changed, but new Graph Change Events will use the new key to encrypt their private data. While the third party can continue to read the data from before the key rotation,6 they cannot observe new changes to the graph, including unfollow Actions of Graph Change Event events for Objects they previously saw. The ability to revoke access to new Graph Change Events, much like the ability to revoke access to actions on their Social Identity, ensures that users maintain control of their graph data and its accessibility across various networks and tools.
**4.2.6 Key Storage**
To maintain portability, the keys used to encrypt private Graph Change Events need to be stored such that they are accessible from multiple devices. These keys can be serialized and encrypted and stored on the blockchain. The wallet has a few options for encrypting data, such as using the private key to deterministically generate a key useful for encryption7 and EIP-2844.\[10] Each key is then able to be retrieved and decrypted by the wallet as needed.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://chainedx.gitbook.io/chainedx-protocol/4.-social-graph.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.