Ceramic 的使命是创建一个无孤岛的网络。本文档提供了 Ceramic 协议的介绍。有关更多技术概述，请参见 Ceramic 技术规范。

• Ceramic 概述

• Ceramic 文件

  • 分散标识符（DID）

    • 3ID

  • 账户链接

  • Tiles

    • 方案

    • 元数据

    • 政策

    • 协议

    • 声明

• 使用案例

  • 自我主权身份

  • 互操作数据

  • 开放 Web 服务

  • 实例

• Ceramic 生态

  • 钱包

  • 数据库

  • 服务

  • 应用程序

• Ceramic 生态联盟

• 时间线

Ceramic 是一种无许可协议，用于创建和访问可变的、防篡改的文档，这些文档是无孤岛网络的基础。Ceramic 的基础设施为公共和互操作的重要信息提供了可验证的、反集权的事实来源。通过将关键信息从孤立的服务器迁移到受数字签名和共识管理的公共空间，Ceramic 使用户和应用程序能够摆脱信息和基础设施孤岛，并使开发人员能够以可组合和高效的方式进行构建。Ceramic 为身份、数据和服务做了区块链为资产做的事情。

因为参与者可以在没有任何集中服务的情况下为任何类型的信息创建和解析文档，Ceramic 解锁了网络上所有平台和服务之间的互操作性。Ceramic 是存储需要保证信任、跨平台互操作性和多方消费的信息的理想选择。这使得 Ceramic 非常适合存储分散标识符及其相关元数据、服务使用策略、访问控制权限、数据模式和其他文档，这些文档共同使钱包和应用程序能够访问由可互操作身份、数据库和服务组成的动态和未捆绑的生态系统。Ceramic 支持：

• 便携式，自我主权身份

• 可互操作的用户和应用程序数据

• 打开Web服务，无需新帐户或登录

有关详细信息，请直接跳转到用例或查看示例。

Ceramic 的全球可互操作资源生态系统允许开发人员以前所未有的模块化、信任和规模构建可组合的应用程序。Ceramic 是构建更加连接、透明和以用户为中心的互联网的可信基础。

尽管云服务、SaaS工具和应用编程接口业务带来了好处，但构建一个功能齐全的产品或服务仍然极其复杂、脆弱和有限。即使是简单的应用程序也需要部署和维护后端，保护和管理用户身份和数据，并将错综复杂的应用编程接口和服务捆绑在一起。早期做出的选择通常会将开发人员锁定在与技术提供商的长期关系中，供应商利用了这种关系。让产品的增值与其他产品和服务互操作通常是困难和不可预测的。所有这些都是因为基础设施、信息和访问控制对于每个单独的应用程序都是不必要的复制和孤立的。

为了解决这些重复、零碎和不安全的问题，互联网需要一个灵活的公共基础设施，参与者可以在其中存储可验证的信息，这些信息在所有应用程序中都是普遍可发现和可访问的。通过将标识符、其关联数据和服务保留在公共域而不是孤立的应用程序服务器上，所有参与者都可以在整个网络中访问它们。在这个模型中，参与者直接定义和控制他们的资源，与其他人共享（或不共享）这些资源，并将他们的身份和元数据带到不同的体验中。

除了为用户提供更多的代理和控制之外，这种模式还极大地简化了开发人员的体验。开发人员可以专注于产品的附加值，而不是花费精力管理数据和将各种服务捆绑在一起。每个应用程序都可以简单地查询他们需要的信息和访问权限。数据可以在不损害隐私的情况下轻松地在不同产品之间共享。体验可以根据用户的偏好实时组合。双边账户注册和协议可以被取消，取而代之的是无摩擦的服务支付渠道。

所有这些都让产品和服务从需要执行非关键功能、协调服务和数据、担心用户信任和责任，或者通过许多摩擦点争先恐后地吸引和留住用户中解放出来。相反，开发人员可以简单地构建一个产品，插入已经存在的用户、数据和服务无缝协作的生态系统。随着时间的推移，这将导致更有针对性的镜像服务和微应用程序正在开发中，而不是我们今天看到的庞然大物。

可组合网络需要一个无许可、以身份为中心的互操作性协议，为应用程序提供他们需要的所有信息，以便轻松发现、路由到、访问用户的资源并与之交互，而不管用户带来了哪个钱包、哪个应用程序创建了数据或资源位于何处。该协议必须：

1. 无许可地注册可互操作身份；

2. 用多个私钥私下控制这个身份；

3. 将公钥和帐户公开关联到此身份；

4. 公开或私下将资源与此身份关联；

5. 为资源设置权限；

6. 对资源进行访问控制；

7. 互操作签署以及/或加密信息；和

8. 撤消资源的私钥、公钥和权限。

除了这些基本要求之外，旨在解锁互操作性的协议还应允许应用程序和服务：

1. 发布元数据和定义；

2. 发布数据模式；以及

3. 发布策略和服务协议。

最后，一个旨在使构建强大应用程序变得更简单的解决方案必须易于开发人员使用。它必须符合现有的思维和开发模型，不增加额外的负担，并随着新的用例和复杂性很好地扩展。

Ceramic 提供了一个可验证文档的通用图。Ceramic 文档被签名，仅附加对象存储在IPFS中，使用IPLD编码，并锚定在一个或多个区块链中。由于其依赖于IPFS/IPLD和各种区块链的混合设计，Ceramic 的文档图具有互操作性、可拓展性、无许可性和低成本（取决于区块链锚服务）。

文档是一个灵活的原语，可以建模来表示许多东西，但是每个文档必须符合协议支持的特定文档类型。文档指定了管理文档有效更新的规则，如签名和状态转换。这允许 Ceramic 节点以分散的方式验证给定文档的状态。

Ceramic 目前支持三种标准文档类型： 3ID、帐户链接和 Tiles。以下是找到这些文档类型的一些常见使用方式。如果您的用例不适合其中一个文档类型，您可以通过在 Ceramic 规格存储库中提交一个问题来向协议添加新的文档类型。

了解有关 Ceramic 文件的更多信息。

DID 是全局唯一的标识，用于在 Ceramic 网络上签署文档，也用于与任意链下服务和数据交互。更具体地说，它们是抽象的、与密钥无关的接口，用于唯一识别实体、互操作地签名和加密信息、授权验证/访问入口对服务的控制以及存储对额外资源的映射。Ceramic 不假设 DID 代表什么样的实体，因此它们可以是用户、组织、应用程序、服务、设备等。DID 可以由一个或多个私钥控制，提供跨钱包和平台的灵活性和互操作性。

Ceramic 上第一个也是最广泛使用的 DID 方法是 3ID。超过15,000个 3ID 已经在生产中使用。符合 W3C DID 规范的其他 DID 方法可以作为额外的文档类型添加到网络中。

详细了解 3ID 或查看示例。

帐户链接是 Ceramic 支持的第二种文档类型。帐户链接是可验证的公共映射，允许 DID 证明它拥有一个不同的公共密码身份，该身份也能够签名，如公钥、智能合同或其他 DID。

详细了解帐户链接。

Tiles 是 Ceramic 支持的第三种文档类型，是文档的最通用形式，几乎可以用来表示任何类型的信息。Tiles 是一种通过一个或多个 DID 进行可验证声明的方式。 Tiles 可以作为独立对象，也可以引用其他 Tiles 。这允许各种 Tiles 之间的可组合性，创建可验证、可变信息的关系图。有关 Tiles 将如何在 Ceramic 上使用的几个示例，请参见下面。

详细了解 Tiles 。

Tiles 的第一个用例是创建可验证的、全局可用的数据模式。模式 Tiles 允许用户定义一个可以被世界上任何地方的任何人使用的规范模式，鼓励多方围绕标准模式汇聚。这使得模式 Tiles 本身很有价值。模式 Tiles 还用于为其他 Tiles 中包含的信息提供结构。因此，模式 Tiles 是其他 Tiles 的核心构建块，例如下面的 Tiles 。模式 Tiles 可以被视为其他 Tiles 的模板。

Tiles 用于表达关于 Ceramic DID的额外元数据或上下文。至少，DID 需要一个 DID 管理器 Tiles ，以便它们可以由一个或多个私钥控制。其他元数据需求将根据DID表示的实体类型和用例而异。

• DID Manager：包含允许一个或多个私钥控制 DID 所需的信息

• 公共简介：提供一个 DID 的上下文

  • 基本：一般配置文件元数据，如名称、图像、logo 等。

• 身份链接：允许其他人验证非加密标识符属于一个 DID

  • 社交链接：公共映射到 twitter、github 等。

  • DNS 链接：到域名的公共映射

• 资源链接：允许其他人验证资源是否属于 DID

  • 数据链接：映射到各种数据源，如数据库、可验证的声明、注册表等。

  • 服务链接：服务和 API 的映射

政策

Tiles 围绕特定服务的设计或访问所需的访问控制要求和权限定义更明确、更具体的术语。例如，政策可以定义应用程序的数据模型、服务的术语和要求，或者用户访问其数据的权限。

• 收集政策：用于定义应用的数据模型（数据库类型加上对模式 Tiles 的引用）

• 服务政策： 服务条款和使用资源的要求，可能包括服务端点和支付信息

• 隐私政策：用户管理的资源访问控制权限

Tiles 用于在 DID 之间形成明确的协议。这方面的一个例子是服务协议，这是服务提供商和购买者之间的多方协议（即数据托管）。

Tiles 用于创建关于其他 DID 的声明。为了实现这一点，他们可以创建一个可验证的声明，这是创建签名声明或数据的灵活标准。如果收件人接受了可验证的声明，则包含在收件人的上述元数据中。

大多数使用Ceramic 的生产系统和应用程序将结合这些简单的原语（DID、帐户链接和 Tiles ）来享受简单、互操作性和规模，只有当身份、资源和服务从应用程序孤岛中分离出来时，这才是可能的。以下是一些基于 Ceramic 的强大用例：

自我主权身份（SSI）描述了一个系统，参与者可以使用一个或多个私钥无许可地创建和控制他们的数字身份。从技术上讲，SSI 可以由任何分散的非对称密码系统启用，在这种系统中，公钥（身份）由比特币或以太坊等私钥（密码）控制。然而，这种类型的系统将仅限于注册这些身份的网络以及单个私钥账户。这两个约束起到了孤岛的作用，阻止了这种身份在其他环境中的互操作。

为了使身份在平台和密钥之间真正具有灵活性和可携带性，从而使其在实践中更加有用，我们需要一个位于区块链账户之上的额外身份抽象。这就是 DID 的价值。在 Ceramic 上，DID 作为全球公共身份，可以由任何区块链或密码系统的任何数量的私钥控制。DID 提供了一个单一的接口，所有者可以使用该接口来识别自己、互操作地签名消息、加密数据以及授权/获得与用户所在区块链无关的链下服务。DID 是私钥和网络锁的解毒剂。

SSI 通常不仅仅包括对标识符的直接控制。大多数情况下，该标识符需要更多的情景，以便其他人可以与之交互，例如配置文件详细信息。Ceramic Tiles 允许 DID 所有者向其 SSI 添加元数据和其他信息或资源，从而形成灵活和动态的 SSI 解决方案。

对于强大的互操作体验，需要跨应用程序的数据可移植性。这需要几个核心功能。首先，我们需要有一种通用的方式，让用户跨平台识别自己，这样我们就可以知道哪些数据是他们的。这由 SSI/DIDs 处理（见上文）。第二，我们需要知道这些数据在哪里，以便请求它。第三，我们需要能够访问这些数据，在用户许可下。最后，我们需要知道数据的模式，这样我们就可以在应用程序中使用它，而无需手动处理。

Ceramic 使这一点对所有各方都很简单。通过映射到用户的数据资源中，Ceramic 为应用程序（和其他数据消费者）提供了一种有效发现信息所在位置的方法，无论是在特定的服务器上还是在公共网络上。Ceramic 还允许 Ceramic DID 通过 Tiles 为其数据资源定义访问控制策略，Ceramic 为用户提供了一种以身份为中心的方式，让消费者访问他们的信息，而不管它住在哪里。访问控制不是发生在服务器上，而是直接发生在用户身上。最后，Ceramic 允许应用程序为任何被保存的数据定义模式，以便数据消费者可以先验地知道将返回的数据的形式，即使它是加密的。

这些功能允许用户在各种应用程序中无摩擦地控制和共享他们的数据，同时也允许开发人员使用比以往任何时候都更丰富、更高质量的数据集——而不存储任何数据。

互操作性难题的最后一部分是对网络服务提供更开放的访问。Ceramic 上的所有服务提供商（即数据托管、索引、锚定、支付或其他任意 web/API 服务）都可以服务来自所有其他身份的请求，而不需要双边的一次性账户。服务提供商可以取消创建账户和使用应用编程接口密钥访问服务的要求。只要用户、应用程序或其他服务满足某些预定义的条件，就可以访问服务，而不是通过应用程序后端的应用编程接口密钥。这使得服务提供商能够消除访问其服务时的所有摩擦，并在每次使用（或其他预定义）的基础上扩大其客户群。

例如，一个托管需要许多不同方访问的用户数据的服务提供商现在可以为所有用户提供服务，而不需要每个用户都有服务账户。使用 Ceramic，数据托管服务可以定义他们的服务，并创建服务策略，其中包括消费者访问服务必须满足的要求。当用户（或应用程序）选择使用此服务将其数据托管在由 Ceramic DED 控制的访问数据库中时，用户（或应用程序）随后将此资源添加到其 DID 中。当其他消费者想要请求此信息时，他们需要向用户请求访问权限，一旦获得批准，然后在数据返回之前满足托管服务的要求（如支付或其他）。

尽管 Ceramic 提供了服务接受各方每次使用支付所需的信息，但 Ceramic 协议本身并不处理支付。因为这些交易很可能是小额支付，Ceramic 与新兴的无许可密码小额支付网络（如E VM 区块链上的 Connext Network 和比特币上的闪电网络）极其互补。在这些系统最为缺少许可的版本中，服务提供商和最终用户将运行支付节点并进行交易。在更实用的版本中，这些责任可以委托给第三支付处理器。这种模式还允许应用程序代表用户支付服务费用。我们认为这在短期内最有意义。

虽然此示例描述了数据托管服务，但 Ceramic 服务策略几乎可以用于任何类型的服务。

为了让一切变得更加具体，让我们深入研究 3Box 如何依赖 Ceramic 来实现一个可互操作的、用户控制的数据管理系统。3Box 是一个框架，允许开发人员将用户和应用程序数据存储在由用户控制的开放数据托管服务网络上，而不是孤立的应用服务器上。用户始终控制自己的数据，并可以选择将其许可给其他应用程序，使其可以跨平台和应用程序共享。实现这一 3Box依赖于自我主权身份、可互操作数据和开放的网络服务。

对于自主权身份和启用用户管理的访问控制，3Box 使用 Ceramic 的 3ID DID 方法，该方法允许用户使用所有现有的私人钱包密钥来控制他们的身份、信息和服务。为了启用可互操作的数据和共享访问网络服务，3Box 依赖于以下一组由在系统中扮演角色的各种参与者创建的 Tiles ，包括应用程序、服务和用户：

Tile

Description

Function

模式

描述特定数据库中使用的数据模式

允许开发人员定义其数据模式，或使用现有的数据模式

收集政策

描述数据库的集合。链接到 模式 Tiles

允许应用程序定义其数据库及其使用的数据模型，以便其他人可以轻松使用数据

服务政策

描述接受输入并产生输出的简单功能。在这种情况下，它用于在“收集政策”中托管数据库

允许服务提供商定义其服务或 API 以及访问要求

隐私政策

在“收集政策”中描述对数据库的用户管理的访问控制权限

允许用户设置权限并控制其隐私，同时跨应用共享数据

此功能集合允许应用程序 A 将用户 B 在托管服务上的数据存储在由用户 B 的 3ID 控制的数据库中。用户 B 现在可以转到应用程序 C，并允许他们从应用程序 A 访问他们的数据。要从托管服务接收数据，应用程序 C 必须满足托管服务服务的服务政策定义的要求，其中可能包括支付信息。

到目前为止，您已经明白，Ceramic 支持一个多样化的、可互操作的生态系统的出现，该生态系统由用户控制的钱包、数据存储和基础设施服务组成，允许开发人员构建轻量级、可组合的协作应用程序。以下是您可以参与的方式。

集成平台不可知、自我主权身份：让钱包的用户能够使用他们的 DID 而不是特定的私钥管理他们的数据和其他链下服务。DID 是从单个密钥对和合同帐户中抽象出来的，消除了私钥锁定。DID 用于与用户已经拥有的所有钱包密钥进行可互操作的数据签名、加密和服务授权。

集成统一的、用户管理的访问控制系统：使您的数据库的访问控制系统与 Ceramic 3ID 兼容，以便用户可以用一个身份管理存储在所有数据库中的信息，并允许不同的应用程序访问他们的信息。Ceramic 将首先支持基于 IPFS 的对等数据库 OrbitDB 和 Textile。

提供开放、共享的访问服务：提供 Ceramic 兼容的服务，并在 Ceramic 网络上列出您的基础设施，以允许其他人与您的服务交互，即使他们不是您的直接客户。

构建可组合的、以用户为中心的应用程序：使用 Ceramic 的互联、互操作服务生态系统构建您的应用程序。与支持 Ceramic 服务协议的基础设施提供商一起，将您的用户和应用程序数据存储在支持 Ceramic 的数据库中。还可以使用 Ceramic 发现可用的数据源来填充您的应用程序。

Ceramic 生态系统联盟是一个由积极为 Ceramic 协议的研究和开发做出贡献的组织、社区和个人组成的协作团体，将 Ceramic 标准集成到他们的产品中，或者在 Ceramic 网络上构建服务。成为会员并在此注册。

Ceramic 的核心贡献者正在努力发布网络的第一个版本。我们已经有一些 js-Ceramic 的工作代码，理想情况下将在今年夏天的某个时候投入生产。

TG：https://t.me/CryptoDigger88 币用：https://0.plus/CryptoDigger88

Dis： https://discord.gg/djHttK592U

Twitter：@ZF_lab

Ceramic 的使命是创建一个无孤岛的网络。本文档提供了 Ceramic 协议的介绍。有关更多技术概述，请参见 Ceramic 技术规范。

• Ceramic 概述

• Ceramic 文件

  • 分散标识符（DID）

    • 3ID

  • 账户链接

  • Tiles

    • 方案

    • 元数据

    • 政策

    • 协议

    • 声明

• 使用案例

  • 自我主权身份

  • 互操作数据

  • 开放 Web 服务

  • 实例

• Ceramic 生态

  • 钱包

  • 数据库

  • 服务

  • 应用程序

• Ceramic 生态联盟

• 时间线

Ceramic 是一种无许可协议，用于创建和访问可变的、防篡改的文档，这些文档是无孤岛网络的基础。Ceramic 的基础设施为公共和互操作的重要信息提供了可验证的、反集权的事实来源。通过将关键信息从孤立的服务器迁移到受数字签名和共识管理的公共空间，Ceramic 使用户和应用程序能够摆脱信息和基础设施孤岛，并使开发人员能够以可组合和高效的方式进行构建。Ceramic 为身份、数据和服务做了区块链为资产做的事情。

因为参与者可以在没有任何集中服务的情况下为任何类型的信息创建和解析文档，Ceramic 解锁了网络上所有平台和服务之间的互操作性。Ceramic 是存储需要保证信任、跨平台互操作性和多方消费的信息的理想选择。这使得 Ceramic 非常适合存储分散标识符及其相关元数据、服务使用策略、访问控制权限、数据模式和其他文档，这些文档共同使钱包和应用程序能够访问由可互操作身份、数据库和服务组成的动态和未捆绑的生态系统。Ceramic 支持：

• 便携式，自我主权身份

• 可互操作的用户和应用程序数据

• 打开Web服务，无需新帐户或登录

有关详细信息，请直接跳转到用例或查看示例。

Ceramic 的全球可互操作资源生态系统允许开发人员以前所未有的模块化、信任和规模构建可组合的应用程序。Ceramic 是构建更加连接、透明和以用户为中心的互联网的可信基础。

尽管云服务、SaaS工具和应用编程接口业务带来了好处，但构建一个功能齐全的产品或服务仍然极其复杂、脆弱和有限。即使是简单的应用程序也需要部署和维护后端，保护和管理用户身份和数据，并将错综复杂的应用编程接口和服务捆绑在一起。早期做出的选择通常会将开发人员锁定在与技术提供商的长期关系中，供应商利用了这种关系。让产品的增值与其他产品和服务互操作通常是困难和不可预测的。所有这些都是因为基础设施、信息和访问控制对于每个单独的应用程序都是不必要的复制和孤立的。

为了解决这些重复、零碎和不安全的问题，互联网需要一个灵活的公共基础设施，参与者可以在其中存储可验证的信息，这些信息在所有应用程序中都是普遍可发现和可访问的。通过将标识符、其关联数据和服务保留在公共域而不是孤立的应用程序服务器上，所有参与者都可以在整个网络中访问它们。在这个模型中，参与者直接定义和控制他们的资源，与其他人共享（或不共享）这些资源，并将他们的身份和元数据带到不同的体验中。

除了为用户提供更多的代理和控制之外，这种模式还极大地简化了开发人员的体验。开发人员可以专注于产品的附加值，而不是花费精力管理数据和将各种服务捆绑在一起。每个应用程序都可以简单地查询他们需要的信息和访问权限。数据可以在不损害隐私的情况下轻松地在不同产品之间共享。体验可以根据用户的偏好实时组合。双边账户注册和协议可以被取消，取而代之的是无摩擦的服务支付渠道。

所有这些都让产品和服务从需要执行非关键功能、协调服务和数据、担心用户信任和责任，或者通过许多摩擦点争先恐后地吸引和留住用户中解放出来。相反，开发人员可以简单地构建一个产品，插入已经存在的用户、数据和服务无缝协作的生态系统。随着时间的推移，这将导致更有针对性的镜像服务和微应用程序正在开发中，而不是我们今天看到的庞然大物。

可组合网络需要一个无许可、以身份为中心的互操作性协议，为应用程序提供他们需要的所有信息，以便轻松发现、路由到、访问用户的资源并与之交互，而不管用户带来了哪个钱包、哪个应用程序创建了数据或资源位于何处。该协议必须：

1. 无许可地注册可互操作身份；

2. 用多个私钥私下控制这个身份；

3. 将公钥和帐户公开关联到此身份；

4. 公开或私下将资源与此身份关联；

5. 为资源设置权限；

6. 对资源进行访问控制；

7. 互操作签署以及/或加密信息；和

8. 撤消资源的私钥、公钥和权限。

除了这些基本要求之外，旨在解锁互操作性的协议还应允许应用程序和服务：

1. 发布元数据和定义；

2. 发布数据模式；以及

3. 发布策略和服务协议。

最后，一个旨在使构建强大应用程序变得更简单的解决方案必须易于开发人员使用。它必须符合现有的思维和开发模型，不增加额外的负担，并随着新的用例和复杂性很好地扩展。

Ceramic 提供了一个可验证文档的通用图。Ceramic 文档被签名，仅附加对象存储在IPFS中，使用IPLD编码，并锚定在一个或多个区块链中。由于其依赖于IPFS/IPLD和各种区块链的混合设计，Ceramic 的文档图具有互操作性、可拓展性、无许可性和低成本（取决于区块链锚服务）。

文档是一个灵活的原语，可以建模来表示许多东西，但是每个文档必须符合协议支持的特定文档类型。文档指定了管理文档有效更新的规则，如签名和状态转换。这允许 Ceramic 节点以分散的方式验证给定文档的状态。

Ceramic 目前支持三种标准文档类型： 3ID、帐户链接和 Tiles。以下是找到这些文档类型的一些常见使用方式。如果您的用例不适合其中一个文档类型，您可以通过在 Ceramic 规格存储库中提交一个问题来向协议添加新的文档类型。

了解有关 Ceramic 文件的更多信息。

DID 是全局唯一的标识，用于在 Ceramic 网络上签署文档，也用于与任意链下服务和数据交互。更具体地说，它们是抽象的、与密钥无关的接口，用于唯一识别实体、互操作地签名和加密信息、授权验证/访问入口对服务的控制以及存储对额外资源的映射。Ceramic 不假设 DID 代表什么样的实体，因此它们可以是用户、组织、应用程序、服务、设备等。DID 可以由一个或多个私钥控制，提供跨钱包和平台的灵活性和互操作性。

Ceramic 上第一个也是最广泛使用的 DID 方法是 3ID。超过15,000个 3ID 已经在生产中使用。符合 W3C DID 规范的其他 DID 方法可以作为额外的文档类型添加到网络中。

详细了解 3ID 或查看示例。

帐户链接是 Ceramic 支持的第二种文档类型。帐户链接是可验证的公共映射，允许 DID 证明它拥有一个不同的公共密码身份，该身份也能够签名，如公钥、智能合同或其他 DID。

详细了解帐户链接。

Tiles 是 Ceramic 支持的第三种文档类型，是文档的最通用形式，几乎可以用来表示任何类型的信息。Tiles 是一种通过一个或多个 DID 进行可验证声明的方式。 Tiles 可以作为独立对象，也可以引用其他 Tiles 。这允许各种 Tiles 之间的可组合性，创建可验证、可变信息的关系图。有关 Tiles 将如何在 Ceramic 上使用的几个示例，请参见下面。

详细了解 Tiles 。

Tiles 的第一个用例是创建可验证的、全局可用的数据模式。模式 Tiles 允许用户定义一个可以被世界上任何地方的任何人使用的规范模式，鼓励多方围绕标准模式汇聚。这使得模式 Tiles 本身很有价值。模式 Tiles 还用于为其他 Tiles 中包含的信息提供结构。因此，模式 Tiles 是其他 Tiles 的核心构建块，例如下面的 Tiles 。模式 Tiles 可以被视为其他 Tiles 的模板。

Tiles 用于表达关于 Ceramic DID的额外元数据或上下文。至少，DID 需要一个 DID 管理器 Tiles ，以便它们可以由一个或多个私钥控制。其他元数据需求将根据DID表示的实体类型和用例而异。

• DID Manager：包含允许一个或多个私钥控制 DID 所需的信息

• 公共简介：提供一个 DID 的上下文

  • 基本：一般配置文件元数据，如名称、图像、logo 等。

• 身份链接：允许其他人验证非加密标识符属于一个 DID

  • 社交链接：公共映射到 twitter、github 等。

  • DNS 链接：到域名的公共映射

• 资源链接：允许其他人验证资源是否属于 DID

  • 数据链接：映射到各种数据源，如数据库、可验证的声明、注册表等。

  • 服务链接：服务和 API 的映射

政策

Tiles 围绕特定服务的设计或访问所需的访问控制要求和权限定义更明确、更具体的术语。例如，政策可以定义应用程序的数据模型、服务的术语和要求，或者用户访问其数据的权限。

• 收集政策：用于定义应用的数据模型（数据库类型加上对模式 Tiles 的引用）

• 服务政策： 服务条款和使用资源的要求，可能包括服务端点和支付信息

• 隐私政策：用户管理的资源访问控制权限

Tiles 用于在 DID 之间形成明确的协议。这方面的一个例子是服务协议，这是服务提供商和购买者之间的多方协议（即数据托管）。

Tiles 用于创建关于其他 DID 的声明。为了实现这一点，他们可以创建一个可验证的声明，这是创建签名声明或数据的灵活标准。如果收件人接受了可验证的声明，则包含在收件人的上述元数据中。

大多数使用Ceramic 的生产系统和应用程序将结合这些简单的原语（DID、帐户链接和 Tiles ）来享受简单、互操作性和规模，只有当身份、资源和服务从应用程序孤岛中分离出来时，这才是可能的。以下是一些基于 Ceramic 的强大用例：

自我主权身份（SSI）描述了一个系统，参与者可以使用一个或多个私钥无许可地创建和控制他们的数字身份。从技术上讲，SSI 可以由任何分散的非对称密码系统启用，在这种系统中，公钥（身份）由比特币或以太坊等私钥（密码）控制。然而，这种类型的系统将仅限于注册这些身份的网络以及单个私钥账户。这两个约束起到了孤岛的作用，阻止了这种身份在其他环境中的互操作。

为了使身份在平台和密钥之间真正具有灵活性和可携带性，从而使其在实践中更加有用，我们需要一个位于区块链账户之上的额外身份抽象。这就是 DID 的价值。在 Ceramic 上，DID 作为全球公共身份，可以由任何区块链或密码系统的任何数量的私钥控制。DID 提供了一个单一的接口，所有者可以使用该接口来识别自己、互操作地签名消息、加密数据以及授权/获得与用户所在区块链无关的链下服务。DID 是私钥和网络锁的解毒剂。

SSI 通常不仅仅包括对标识符的直接控制。大多数情况下，该标识符需要更多的情景，以便其他人可以与之交互，例如配置文件详细信息。Ceramic Tiles 允许 DID 所有者向其 SSI 添加元数据和其他信息或资源，从而形成灵活和动态的 SSI 解决方案。

对于强大的互操作体验，需要跨应用程序的数据可移植性。这需要几个核心功能。首先，我们需要有一种通用的方式，让用户跨平台识别自己，这样我们就可以知道哪些数据是他们的。这由 SSI/DIDs 处理（见上文）。第二，我们需要知道这些数据在哪里，以便请求它。第三，我们需要能够访问这些数据，在用户许可下。最后，我们需要知道数据的模式，这样我们就可以在应用程序中使用它，而无需手动处理。

Ceramic 使这一点对所有各方都很简单。通过映射到用户的数据资源中，Ceramic 为应用程序（和其他数据消费者）提供了一种有效发现信息所在位置的方法，无论是在特定的服务器上还是在公共网络上。Ceramic 还允许 Ceramic DID 通过 Tiles 为其数据资源定义访问控制策略，Ceramic 为用户提供了一种以身份为中心的方式，让消费者访问他们的信息，而不管它住在哪里。访问控制不是发生在服务器上，而是直接发生在用户身上。最后，Ceramic 允许应用程序为任何被保存的数据定义模式，以便数据消费者可以先验地知道将返回的数据的形式，即使它是加密的。

这些功能允许用户在各种应用程序中无摩擦地控制和共享他们的数据，同时也允许开发人员使用比以往任何时候都更丰富、更高质量的数据集——而不存储任何数据。

互操作性难题的最后一部分是对网络服务提供更开放的访问。Ceramic 上的所有服务提供商（即数据托管、索引、锚定、支付或其他任意 web/API 服务）都可以服务来自所有其他身份的请求，而不需要双边的一次性账户。服务提供商可以取消创建账户和使用应用编程接口密钥访问服务的要求。只要用户、应用程序或其他服务满足某些预定义的条件，就可以访问服务，而不是通过应用程序后端的应用编程接口密钥。这使得服务提供商能够消除访问其服务时的所有摩擦，并在每次使用（或其他预定义）的基础上扩大其客户群。

例如，一个托管需要许多不同方访问的用户数据的服务提供商现在可以为所有用户提供服务，而不需要每个用户都有服务账户。使用 Ceramic，数据托管服务可以定义他们的服务，并创建服务策略，其中包括消费者访问服务必须满足的要求。当用户（或应用程序）选择使用此服务将其数据托管在由 Ceramic DED 控制的访问数据库中时，用户（或应用程序）随后将此资源添加到其 DID 中。当其他消费者想要请求此信息时，他们需要向用户请求访问权限，一旦获得批准，然后在数据返回之前满足托管服务的要求（如支付或其他）。

尽管 Ceramic 提供了服务接受各方每次使用支付所需的信息，但 Ceramic 协议本身并不处理支付。因为这些交易很可能是小额支付，Ceramic 与新兴的无许可密码小额支付网络（如E VM 区块链上的 Connext Network 和比特币上的闪电网络）极其互补。在这些系统最为缺少许可的版本中，服务提供商和最终用户将运行支付节点并进行交易。在更实用的版本中，这些责任可以委托给第三支付处理器。这种模式还允许应用程序代表用户支付服务费用。我们认为这在短期内最有意义。

虽然此示例描述了数据托管服务，但 Ceramic 服务策略几乎可以用于任何类型的服务。

为了让一切变得更加具体，让我们深入研究 3Box 如何依赖 Ceramic 来实现一个可互操作的、用户控制的数据管理系统。3Box 是一个框架，允许开发人员将用户和应用程序数据存储在由用户控制的开放数据托管服务网络上，而不是孤立的应用服务器上。用户始终控制自己的数据，并可以选择将其许可给其他应用程序，使其可以跨平台和应用程序共享。实现这一 3Box依赖于自我主权身份、可互操作数据和开放的网络服务。

对于自主权身份和启用用户管理的访问控制，3Box 使用 Ceramic 的 3ID DID 方法，该方法允许用户使用所有现有的私人钱包密钥来控制他们的身份、信息和服务。为了启用可互操作的数据和共享访问网络服务，3Box 依赖于以下一组由在系统中扮演角色的各种参与者创建的 Tiles ，包括应用程序、服务和用户：

Tile

Description

Function

模式

描述特定数据库中使用的数据模式

允许开发人员定义其数据模式，或使用现有的数据模式

收集政策

描述数据库的集合。链接到 模式 Tiles

允许应用程序定义其数据库及其使用的数据模型，以便其他人可以轻松使用数据

服务政策

描述接受输入并产生输出的简单功能。在这种情况下，它用于在“收集政策”中托管数据库

允许服务提供商定义其服务或 API 以及访问要求

隐私政策

在“收集政策”中描述对数据库的用户管理的访问控制权限

允许用户设置权限并控制其隐私，同时跨应用共享数据

此功能集合允许应用程序 A 将用户 B 在托管服务上的数据存储在由用户 B 的 3ID 控制的数据库中。用户 B 现在可以转到应用程序 C，并允许他们从应用程序 A 访问他们的数据。要从托管服务接收数据，应用程序 C 必须满足托管服务服务的服务政策定义的要求，其中可能包括支付信息。

到目前为止，您已经明白，Ceramic 支持一个多样化的、可互操作的生态系统的出现，该生态系统由用户控制的钱包、数据存储和基础设施服务组成，允许开发人员构建轻量级、可组合的协作应用程序。以下是您可以参与的方式。

集成平台不可知、自我主权身份：让钱包的用户能够使用他们的 DID 而不是特定的私钥管理他们的数据和其他链下服务。DID 是从单个密钥对和合同帐户中抽象出来的，消除了私钥锁定。DID 用于与用户已经拥有的所有钱包密钥进行可互操作的数据签名、加密和服务授权。

集成统一的、用户管理的访问控制系统：使您的数据库的访问控制系统与 Ceramic 3ID 兼容，以便用户可以用一个身份管理存储在所有数据库中的信息，并允许不同的应用程序访问他们的信息。Ceramic 将首先支持基于 IPFS 的对等数据库 OrbitDB 和 Textile。

提供开放、共享的访问服务：提供 Ceramic 兼容的服务，并在 Ceramic 网络上列出您的基础设施，以允许其他人与您的服务交互，即使他们不是您的直接客户。

构建可组合的、以用户为中心的应用程序：使用 Ceramic 的互联、互操作服务生态系统构建您的应用程序。与支持 Ceramic 服务协议的基础设施提供商一起，将您的用户和应用程序数据存储在支持 Ceramic 的数据库中。还可以使用 Ceramic 发现可用的数据源来填充您的应用程序。

Ceramic 生态系统联盟是一个由积极为 Ceramic 协议的研究和开发做出贡献的组织、社区和个人组成的协作团体，将 Ceramic 标准集成到他们的产品中，或者在 Ceramic 网络上构建服务。成为会员并在此注册。

Ceramic 的核心贡献者正在努力发布网络的第一个版本。我们已经有一些 js-Ceramic 的工作代码，理想情况下将在今年夏天的某个时候投入生产。

TG：https://t.me/CryptoDigger88 币用：https://0.plus/CryptoDigger88

Dis： https://discord.gg/djHttK592U

Twitter：@ZF_lab