ComposeDB

ComposeDB uses GraphQL schemas to define interoperable data models, allowing developers to create reusable data types. These models are stored as CIPs (Composable Indexing Protocols) on the Ceramic network, enabling seamless data composability across applications. Key aspects include:

• Model Reusability: Import and extend existing public data models.
• GraphQL Interface: Query and mutate data using a familiar GraphQL API.
• Deterministic StreamIDs: Each data model and instance gets a unique, content-addressed identifier.

Data in ComposeDB is stored on the Ceramic network, a decentralized protocol for mutable, verifiable streams. This provides data sovereignty and resilience. Core mechanisms are:

• Streams: Mutable data structures anchored to a blockchain (like Ethereum).
• DID-based Signing: All writes are signed by a user's Decentralized Identifier (DID).
• P2P Replication: Data is hosted by a distributed network of nodes, not a central server.

ComposeDB provides a local GraphQL runtime that acts as a write-ahead cache and query engine. It manages the state of relevant streams and handles all read/write operations before syncing to the network. This enables:

• Offline-First Development: Applications can function with local data.
• Optimistic Updates: Immediate UI feedback before network confirmation.
• Complex Queries: Perform joins and filters across composed data models locally.

Every piece of data is cryptographically tied to its owner, creating a verifiable data web. This is achieved through:

• DID PKH (Public Key Hash): Links a user's blockchain account (e.g., 0x...) to their data streams.
• Signed Commits: All updates are signed, creating an immutable audit trail.
• Portability: Users can migrate their data between applications, as they retain control via their private keys.

ComposeDB supports powerful indexing strategies to make composable data efficiently queryable. This includes:

• Composable Indexing Protocols (CIPs): Define how data is indexed and made discoverable.
• Custom Indices: Developers can create indices on any field within a data model.
• Cross-Model Joins: The GraphQL API allows querying related data across different, composed models in a single request.

A primary use case is building decentralized social applications where user data is portable. For example, a profile model can be created once and reused by multiple apps (social, gaming, professional networks). Key components:

• Profile CIP: A standardized schema for user profiles.
• Social Connections: A separate model defining follower/following relationships.
• Content Posts: Another model for user-generated content, all linked via the user's DID.

ComposeDB is foundational for building decentralized social networks (DeSo) and content platforms. It enables:

• User-owned social graphs where connections and posts are portable across apps.
• Interoperable profiles that can be reused, preventing platform lock-in.
• Censorship-resistant content stored on a decentralized network, not a corporate server.

Examples include social apps where a user's profile from one app can seamlessly power their identity in another.

It serves as a backend for creating self-sovereign identity systems. Developers can define data models for:

• Verifiable credentials and attestations linked to a decentralized identifier (DID).
• On-chain and off-chain reputation that accumulates across different dApps and services.
• Composable user data, allowing a user's achievements in one game or protocol to be verified and utilized in another application without centralized intermediaries.

ComposeDB is used to manage evolving metadata for NFTs and other digital assets, moving beyond static JSON files. This enables:

• Upgradable NFTs where traits, artwork, or descriptions can be updated post-mint based on external events or user actions.
• Rich, relational data linking assets to creators, provenance history, and community interactions.
• Cross-platform compatibility, allowing game items or digital collectibles to carry their full history and attributes into different virtual environments.

DAOs and decentralized communities use ComposeDB to structure and query their operational data. Key applications include:

• Transparent governance records with linked proposals, votes, and delegate histories.
• Contributor graphs that map skills, contributions, and project affiliations across the ecosystem.
• Community-managed registries for resources, grants, or members, where the data model can be extended by the community itself without requiring a central dev team to deploy new smart contracts.

It acts as a headless CMS for Web3, allowing teams to manage structured content in a decentralized manner. This is used for:

• Developer documentation that can be collaboratively edited and versioned.
• Decentralized wikis and knowledge bases where ownership and edit history are transparent and verifiable.
• Application configuration data that is user-moderated and resistant to unilateral takedowns, ensuring application resilience.

ComposeDB uses GraphQL schemas to define data models, which are then compiled into CIPs (Composable Indexing Protocols). These models are composable, meaning they can reference and extend other models, creating a flexible, interconnected data graph. This enables:

• Data portability across applications.
• Schema evolution without breaking changes.
• Cross-application data queries via a single interface.

Each piece of data in ComposeDB is a Ceramic stream, a mutable data structure anchored to a Decentralized Identifier (DID). Streams are:

• Owner-controlled: Updated via the user's DID.
• Immutable-by-default: Changes are recorded as commits in an append-only log.
• Replicated across the peer-to-peer Ceramic network for availability. This architecture ensures data sovereignty and censorship resistance.

ComposeDB provides a GraphQL API for reading and writing data, abstracting the underlying decentralized infrastructure. Key features include:

• Single endpoint for querying the entire composed data graph.
• Real-time updates via GraphQL subscriptions.
• Indexing of all data for performant, complex queries.
• Permissioned writes enforced at the protocol level, tied to DIDs.

A primary application is building portable social graphs. For example, a user's profile, connections, and content (posts, likes) can be defined as composable models. This allows:

• A social app to read a user's existing graph from another app.
• Users to maintain a single identity and social data layer.
• New applications to build on top of an existing social ecosystem without vendor lock-in.

ComposeDB is an application runtime built on the Ceramic protocol. Ceramic provides the foundational layer:

• Stream processing for mutable data.
• Consensus via CACAO (Capability Authorization) for access control.
• Anchor service to batch stream updates to a blockchain (like Ethereum). ComposeDB adds the graph database logic, schemas, and query engine on top of this base layer.