Ceramic Stream

A Ceramic Stream is a mutable data structure on a decentralized network that evolves over time through a series of commits, similar to a Git repository for application data. Each stream is identified by a globally unique StreamID and is controlled by a Decentralized Identifier (DID), which acts as the cryptographic owner. The data within a stream is stored as a commit log on the InterPlanetary File System (IPFS), ensuring verifiable provenance and censorship resistance. This model enables data to be updated, composed, and referenced across different applications without centralized control.

The architecture of a stream is defined by its StreamType, a schema that dictates its data model and state transition logic. Common types include TileDocument for general JSON documents and Model for defining data schemas in the Ceramic Tableland ecosystem. Updates to a stream are cryptographically signed commits that append to its log, creating an immutable history. This allows any user to verify the entire lineage of the data, providing strong integrity guarantees and enabling trustless collaboration between applications and users.

Streams enable powerful composability and data interoperability. Because streams are referenced by their immutable StreamID, one application's data can be seamlessly read and updated by another, forming a graph of interconnected data. For example, a user profile stored in one stream can be linked to a social graph or a reputation score in separate streams, all owned by the same DID. This breaks down data silos and allows developers to build on existing data sets, accelerating innovation and user ownership within the Web3 ecosystem.

From a developer's perspective, interacting with streams is facilitated by client libraries like Glaze or the core Ceramic HTTP Client. Operations include creating a stream from a schema, updating its content, and loading its current state. The network uses Consensus mechanisms to handle concurrent updates, ensuring consistency. This design is particularly suited for dynamic, user-centric data such as social profiles, content feeds, decentralized identifiers, and application settings that need to persist across different dApps and services.

In practice, Ceramic Streams form the backbone of user-centric data ecosystems. They power protocols like Ceramic Tableland, where streams define and instantiate data models for decentralized applications. By providing a universal layer for mutable data, streams solve the long-standing challenge of portable, updatable information in blockchain environments, which are typically optimized for immutable asset transfer. This makes them a critical infrastructure component for the next generation of interoperable, user-owned applications on the decentralized web.

A Ceramic Stream is a commit log—a tamper-evident, append-only data structure anchored to a blockchain. Each stream is identified by a unique StreamID and is controlled by a Decentralized Identifier (DID). The stream's state is not stored directly on a blockchain; instead, the network uses the blockchain (like Ethereum or Polygon) as a secure timestamping and ordering layer for the stream's commit hashes. This design separates the cost-intensive consensus of the base layer from the high-frequency data updates, enabling scalable, mutable data for applications.

The core mechanism is the stream state machine, which progresses through a series of commits. Each commit is a signed Ceramic Commit, which can be a Genesis Commit (creating the stream with a schema and initial data), a Signed Commit (an update to the stream's content), or an Anchor Commit (a proof of recency and order, written to a blockchain). The network's nodes, running the js-ceramic implementation, validate each commit against the stream's state transition rules and the controlling DID's signature to deterministically compute the current state.

Streams are composable and can reference other streams, enabling complex, interconnected data graphs. For example, a user profile stream might reference a stream schema that defines its structure and a tile document stream containing the actual profile data. Developers interact with streams via the Ceramic HTTP API or client libraries, performing operations like stream.state = nextContent to create an update commit. The network's peer-to-peer libp2p transport layer propagates these commits, ensuring eventual consistency across nodes without global consensus on content.

This architecture provides cryptographic verifiability: any party can fetch the commit log for a StreamID and independently verify the entire history and current state, ensuring data integrity and provenance without trusting a central server. It enables use cases like user-controlled social graphs, verifiable credentials, and collaborative documents where data must be mutable, owned by users, and interoperable across applications in the decentralized web (Web3).

A Ceramic Stream is a mutable, version-controlled data structure stored on the decentralized Ceramic network, identified by a unique StreamID. Unlike static files or immutable blockchain transactions, a stream is a commit log—a cryptographically verifiable chain of updates where each new state is a commit anchored to the previous one. This structure allows data to evolve over time while maintaining a complete, tamper-proof history, making streams ideal for dynamic applications like user profiles, social graphs, and collaborative documents.

The internal structure of a stream is defined by its StreamType, a schema that dictates the rules for its content and state transitions. Common types include TileDocument streams for generic JSON documents, CAIP-10 Link streams for blockchain account associations, and Model streams that define data schemas for use with the ComposeDB graph database. Each commit in a stream's log contains the updated content, metadata, and a proof linking it to the previous state, secured by the stream controller's DID (Decentralized Identifier).

Streams are fundamentally decentralized; no single entity controls the network or the data. The state of a stream is resolved deterministically by any node by replaying its commit log. Access control is managed via capability-based security, where the stream controller (holder of the private key for its DID) authorizes updates. This model enables user-centric data ownership, where individuals or applications control their own streams, and others can permissionlessly read and verify their entire history.