Social Graph Context
Relevant source files
The following files were used as context for generating this wiki page:
The Social context is a core domain boundary within the LiveCanvas backend architecture responsible for managing interpersonal relationships and visibility policies. It acts as the primary layer for governing interactions between users, specifically handling follower graphs, access requests for private accounts, and restrictive measures such as blocks and mutes.
The scope of this module is strictly defined to decouple relationship logic from other systems. While the Social context determines who can see content, it does not own the content itself (managed by the Content context) or user authentication (managed by the Accounts context). Instead, it provides the authorization logic used by the Feed Context and other consumer layers to filter data based on user-defined privacy settings and relationship states.
Sources: ARCHITECTURE.md:144-150, ARCHITECTURE.md:213-219
Domain Responsibility and Policies
The Social context functions as the policy layer of the application. It evaluates the relationship between a viewer and a creator to determine if specific actions (such as joining a live session or viewing a post) are permissible.
Core Responsibilities
- Follow Relationships: Managing the lifecycle of follows, including requests and approvals for accounts set to private mode.
- Visibility Checks: Providing a source of truth for relationship-based access control.
- Restrictive Actions: Handling blocks (hard access restrictions) and mutes (content filtering).
- Request Management: Processing pending follow requests for users with restricted visibility.
Sources: ARCHITECTURE.md:144-150, ARCHITECTURE.md:217-219
Relationship State Logic
The system uses a set of states to define the current standing between two users. This state is critical for enforcing the "Followers-only" vs "Public" visibility modes found in posts and live sessions.
| State | Description |
|---|---|
ACCEPTED | The follow relationship is active and authorized. |
BLOCKED | A hard restriction exists; overrides all other relationship states. |
REQUESTED | A follow request is pending approval by a private account. |
PUBLIC | No specific follow exists, but the target account is public. |
NONE | No relationship exists and the account may be private. |
Sources: mobile/schema.graphql:439-445
Data Modeling
The Social context relies on specific PostgreSQL tables to persist durable relationship facts. Following project conventions, these tables use bigint primary keys and UUIDv7 :entropy_id identifiers.
Primary Entities
The diagram shows the relationship between users and the social persistence layer where follows and blocks are recorded.
follows: Stores follower-to-account relationships. It includes state management for private accounts, distinguishing between a pendingREQUESTEDstate and anACCEPTEDstate.blocks: Stores hard restrictions. If a block record exists, it overrides any follow-based visibility, effectively severing interaction between the two parties.
Sources: ARCHITECTURE.md:267-273, AGENTS.md:5-7
API Implementation (GraphQL)
The Social context exposes its functionality through the primary GraphQL API. This includes queries for checking relationship status and mutations for altering the social graph.
Queries
Users can query the state of their relationships or view their pending requests.
| Field | Return Type | Description |
|---|---|---|
relationshipState | RelationshipState! | Returns the current state between the viewer and a specific creator. |
isMuted | Boolean! | Checks if the viewer has muted a specific creator. |
viewerPendingFollowRequests | FollowRequestConnection | A Relay-compliant connection of incoming follow requests. |
Sources: mobile/schema.graphql:15-20
Mutations
The context provides several mutations to manage social connections:
The flow shows how mutations transition the relationship state based on account privacy settings.
followUser: Initiates a follow. If the target is private, it creates aREQUESTEDstate.acceptFollowRequest/declineFollowRequest: Used by the owner of a private account to manage incoming requests.blockUser: Creates a hard restriction record.muteUser/unmuteUser: Manages content filtering without severing the follow relationship.
Sources: mobile/schema.graphql:66-73, ARCHITECTURE.md:144-150
Integration with Other Contexts
The Social context is a critical dependency for read-side orchestration, particularly within the Feed and Live contexts.
Visibility Enforcement
When a user attempts to access a resource (like a Live Session or a Post), the system performs a multi-layered check:
- Authentication: Identifies the
current_user(viaAccounts). - Relationship Check: The Social context determines if the viewer is a follower or if a block exists.
- Policy Application: If a resource is marked
FOLLOWERSvisibility, access is granted only if the Social context returns anACCEPTEDstate.
Realtime Security
For Phoenix Channels and WebSockets, the Social context is used during the join phase to validate viewer eligibility. This ensures that users who have been blocked or are not authorized followers cannot receive realtime broadcasts for private sessions.
Sources: ARCHITECTURE.md:310-318, ARCHITECTURE.md:323-328
Conclusion
The Social Graph Context provides the foundational logic for user connectivity and privacy within LiveCanvas. By centralizing follow, block, and mute logic, the system ensures consistent authorization across diverse transport layers (GraphQL and WebSockets). Its separation from content ownership allows the backend to scale visibility checks independently of content delivery, maintaining a modular architecture that supports both public interactions and private, follower-only communities.