Introduction to the Ceramic Protocol
By: Michael Sena
Tags: Ceramic, Ipfs, Decentralization, Blockchain, Protocol

Ceramic Overview

Background Ceramic Documents Ceramic Use Cases Ceramic Ecosystem Ceramic Ecosystem Alliance Ceramic Timeline Ceramic Technical Specification

1. Background

Despite the benefits of cloud services, SaaS tools, and API businesses, building a fully featured product or service is still extremely complex, fragile, and limited. Even simple apps require deploying and maintaining a backend, securing and managing user identities and data, and tying together a tangle of APIs and services. Choices made early often lock developers in to long term relationships with technology providers, which vendors exploit. Making a product’s value-add interoperate with other products and services is often difficult and unpredictable. All of this is because infrastructure, information, and access control are needlessly replicated and siloed for each individual application.

To combat these problems of duplication, fragmentation, and insecurity, the internet needs a flexible public infrastructure where participants can store verifiable information that is universally discoverable and accessible across all applications. By keeping identifiers, their associated data, and services in the public domain instead of on siloed application servers, they can be accessed by all participants across the web. In this model, participants directly define and control their resources, share (or not) these resources with others, and bring their identities and metadata across experiences.

In addition to giving users more agency and control, this model dramatically simplifies the experience for developers as well. Instead of spending effort on managing data and tying together various services, developers can focus on the value-add in their product. Each application can simply query an identity for the information and access they need. Data can be easily shared across products without compromising privacy. Experiences can be composed in real-time to a users preferences. Bilateral service signups and agreements can be done away with, replaced instead by frictionless payment channels for services.

All of this frees products and services from needing to perform non-critical functions, reconciling services and data, worrying about user trust and liability, or scrambling to attract and retain users through many points of friction. Instead, developers can simply build a product that plugs into an already existing ecosystem of users, data, and services that work seamlessly together. Over time, this will result in more targeted micro-services and micro-applications being developed, instead of the behemoths we see today.

Requirements

The composable web needs a permissionless, identity-centric interoperability protocol to provide applications with all the information they need to easily discover, route to, gain access to, and interact with a user’s resources regardless of which wallet users bring, which applications created the data, or where the resources are located. This protocol must:

Permissionlessly register an interoperable identity (DID); Privately control this identity with multiple private keys; Publicly associate public keys and accounts to this identity; Publicly or privately associate resources to this identity; Set permissions for resources; Perform access control to resources; Interoperably sign and/or encrypt information; and Revoke private keys, public keys, and permissions for resources.

In addition to these base requirements, a protocol aiming to unlock interoperability should also allow applications and services to:

Publish metadata and definitions; Publish data schemas; and Publish policies and service agreements.

Finally, a solution aiming to make it simpler to build powerful applications must be easy for developers to use. It must fit with existing mental and development models, add no additional burdens, and scale well with new use cases and complexity.

2. Ceramic Documents

Ceramic provides a universal graph of verifiable documents. Ceramic documents are signed, append-only, tamper-proof objects stored in IPFS, encoded using IPLD, and anchored in one or more blockchains. Due to its hybrid design relying on IPFS/IPLD and various blockchains, Ceramic’s document graph is interoperable, scalable, permissionless, and low cost (variable depending on blockchain anchor service).

Ceramic documents are a flexible primitive that can be modeled to represent many things, however each document must conform to a specific doctype supported by the protocol. Doctypes specify rules that govern what is a valid update to the document such as signatures and state transitions. This allows Ceramic nodes to verify the state of a given document in a decentralized way.

Ceramic currently supports three standard doctypes: 3IDs, account-links, and tiles. Below, find some of the common ways that these doctypes are used. If your use case doesn’t fit into one of these doctypes, you can add new doctypes to the protocol by submitting an issue on the Ceramic specs repository.

Learn more about Ceramic documents.

Decentralized Identifiers (DIDs)

DIDs are globally unique identities used to sign documents on the Ceramic network and also interact with arbitrary off-chain services and data. More specifically, they are abstract, key-agnostic interfaces used to uniquely identify entities, interoperably sign and encrypt information, authorize authentication/access control to services, and store mappings to additional resources. Ceramic makes no assumptions about what kind of entity a DID represents, so they can be users, organizations, applications, services, devices, etc. DIDs can be controlled by one or many private keys, providing flexibility and interoperability across wallets and platforms.

3ID Identity

The first and most widely used DID method on Ceramic is 3ID. More than 15,000 3IDs are already being used in production. Other DID methods that conform to the W3C DID spec may be added to the network as additional doctypes.

Learn more about 3IDs or see an example.

Account Links

Account links are the second doctype supported by Ceramic. Account links are verifiable public mappings that allow a DID to prove that it owns a different public cryptographic identity that is also capable of signing, such as a public key, smart contract, or other DID.

Learn more about account links.

Tiles

Tiles, the third doctype supported by Ceramic, are the most general form of a document and can be used to represent almost any kind of information. Tiles are a way to make verifiable statements by one or more DIDs. Tiles may act as standalone objects or they can reference other tiles. This allows for composability between various tiles, creating a relational graph of verifiable, mutable information. See below for a few examples of how tiles will be used on Ceramic.

Learn more about tiles.

Schemas

The first use case for tiles is creating verifiable, globally-available data schemas. Schema tiles allow a user to define a canonical schema that can be used by anyone anywhere in the world, encouraging multiple parties to converge around standard schemas. This makes schema tiles valuable in their own right. Schema tiles are also used to provide structure to information contained in other tiles. Because of this, schema tiles are the core building block for other tiles, such as those below. Schemas tiles can be thought of as templates for other tiles.

Metadata

Tiles are used to express additional metadata or context about Ceramic DIDs. At a minimum, DIDs need a DID Manager tile so they can be controlled by one or more private keys. Other metadata needs will vary depending on the type of entity that a DID represents and the use case.

DID Manager: Contains information required to allow one or many private keys to control a DID

Public Profile: Provide context about a DID, such as profile metadata (name, image, logo, etc)

Identity Link: Allow others to verify that a non-cryptographic identifier is owned by a DID, such as social links (twitter, github, etc) or DNS links

Resource Link: Allow others to verify that a resource is owned by the DID, such as a data link (data sources, data bases, verifiable claims, registries) or a service link (services, APIs)

Policies

Tiles are used to define more explicit, specific terms around the design of a particular service or the access control requirements and permissions needed to access it. For example, policies can define the data model for an application, terms and requirements of a service, or the permissions set by a user to access their data.

Collection Policy: Used to define an app’s data model (database types plus references to schema tiles)

Service Policy: ToS and requirements for using a resource, may include service endpoint and payment info

Privacy Policy: User-managed access control permissions to their resources

Agreements

Tiles are used to form explicit agreements between DIDs. An example of this would be a Service Agreement, which is a multi-party agreement between a provider and purchaser of a service (i.e. data hosting).

Claims

Tiles are used to create statements about other DIDs; to achieve this they can create a Verifiable Claim tile. Verifiable claims are a flexible standard for creating signed statements or data. If the verifiable claim is accepted by the recipient, is included in the recipient’s metadata above.

3. Ceramic Use Cases

Most production systems and applications that use Ceramic will combine these simple primitives (DIDs, account links, and tiles) to enjoy the simplicity, interoperability, and scale that is only possible when identities, resources, and services are unbundled from wallet or application silos. Here are a few powerful use cases that are built on Ceramic: