Content & Media Context
Relevant source files
The following files were used as context for generating this wiki page:
The Content & Media Context serves as the primary management layer for all durable, user-visible assets and publications within the LiveCanvas ecosystem. Its scope encompasses the lifecycle of posts, story-based content, and the technical metadata required to track media assets stored in external object storage. Unlike the Live Context, which manages transient real-time states, the Content context is responsible for the long-term persistence of records that populate the user's feed and history.
Sources: ARCHITECTURE.md:162-167, ARCHITECTURE.md:213-217
Architectural Overview
The Content system is built on a modular monolith architecture, utilizing PostgreSQL as the system of record for all metadata while offloading binary data to external object storage. The backend interacts with these assets through GraphQL as the primary client API, ensuring strict boundary enforcement between the content storage and the presentation layer.
Data Storage Strategy
- Metadata: PostgreSQL stores all post details, visibility settings, and references to media.
- Binaries: Actual media files (images, videos) live in object storage.
- Referential Integrity: The
media_assetstable acts as the bridge, storing MIME types, processing states, and storage keys.
Sources: ARCHITECTURE.md:144-148, ARCHITECTURE.md:275-281
Context Interaction
The following diagram illustrates how the Content context interacts with other domain boundaries like Accounts and Live sessions.
This diagram shows the relationship between durable content and transient live sessions.
Sources: ARCHITECTURE.md:154-200
Media Asset Management
Media assets are treated as independent entities with specific lifecycles. They transition through various processing states from initial upload intent to final public availability.
Media Lifecycle States
The system tracks the readiness of an asset using the MediaProcessingState enumeration.
| State | Description |
|---|---|
PENDING_UPLOAD | The user has requested an upload but the binary has not been sent. |
UPLOADED | The binary has reached object storage but has not been processed. |
PROCESSED | Media is optimized and ready for public consumption. |
FAILED | An error occurred during processing or upload. |
Sources: mobile/schema.graphql:345-350
Upload Flow
To maintain security, the backend provides signed URLs for direct client-to-storage uploads, minimizing the load on the application server.
The sequence of requesting and executing a secure media upload.
Sources: mobile/schema.graphql:102-106, mobile/schema.graphql:358-368
Posts and Stories
The context differentiates between standard posts and ephemeral-style "stories," though both are governed by similar visibility and expiration rules.
Post Structure
A Post is the primary container for user content. It links authors to specific media assets and applies visibility logic defined by the Social context.
| Field | Type | Description |
|---|---|---|
kind | PostKind | Either STANDARD or STORY. |
visibility | PostVisibility | PUBLIC or FOLLOWERS only. |
mediaAssets | [PostMediaAsset!] | List of associated media objects. |
expiresAt | ISO8601 String | Used primarily for stories to handle auto-deletion/hiding. |
Sources: mobile/schema.graphql:370-394
Content Visibility Logic
Visibility is enforced at the context boundary. If an account is private, content retrieval must verify the requester's relationship status via the Social context.
The logic gate for accessing restricted content.
Sources: ARCHITECTURE.md:320-330
API Implementation
The Content context is primarily interacted with through the following GraphQL operations.
Key Mutations
createPost: Initiates the creation of a standard or story post.requestMediaUpload: Generates the necessary credentials for a new media asset.updatePost: Modifies text or visibility of existing content.deletePost: Removes content and initiates cleanup of associated media references.
Sources: mobile/schema.graphql:45-51
Technical Constraints
- Primary Keys: Relational tables use
bigintprimary keys supplemented by an:entropy_id(UUIDv7) generated by Postgres. - Timestamps: All timestamps must utilize
:utc_datetime_usecfor microsecond precision. - Authorization: Ownership and visibility rules must be re-applied in GraphQL node fetchers to prevent IDOR (
CWE-639) vulnerabilities.
Sources: AGENTS.md:3-12
Summary
The Content & Media Context provides the foundational infrastructure for data persistence in LiveCanvas. By separating binary storage from metadata management and implementing a robust state-based processing pipeline, the system ensures that user posts and media remain durable, secure, and performant. It effectively bridges the gap between active participation (Live/Chat) and the long-term social feed.