ceramicnetwork / cips Goto Github PK

cip: 4
title: Ceramic Javascript API
author: Joel Thorstensson (@oed), Janko Simonovic (@simonovic86)
discussions-to:
status: Last Call
category: Standards
type: Interface
created: 2020-06-05

Simple Summary

This CIP describes the javascript api that is implemented by both ceramic-core and ceramic-http-client. It provides a common interface for interacting with the ceramic network.

Abstract

This CIP provides a standard javascript interface for ceramic that allows developers to interact with a Ceramic instance. The interface includes abstractions that allow developers add their own doctypes, by implementing a simple interface. It also enables the DID provider to be passed to the Ceramic instance regardless if ceramic-core or ceramic-http-client is being used. This is enabled by having an applyRecord function that allows signed records to be passed from the http client to a remote node.

Motivation

Having a standardized interface for using ceramic regardless if you're interacting with a remote node or not is crucial to the decentralization of the protocol. By creating a common api for both the core implementation and the http-client (plus potential future clients) will enable developers to easily swap between remote clients and more decentralized alternatives.

Specification

Below we define two main interfaces. Doctype which is an interface that each doctype in ceramic can extend in various ways, and CeramicApi which is the interface of Ceramic clients.

Doctype

Below the Doctype interface is defined. Any new doctype has to expand this interface in order to expose the functionality of the particular doctype in a developer friendly way. The DoctypeHandler interface is also defined. It provides the function needed in order to verify the state transition function of a particular doctype.

interface DocState {
  // DocState as defined in the implementation
}

interface Context {
    user?: User;
    ipfs?: Ipfs; // an ipfs instance
    resolver?: Resolver; // a DID resolver instance
    provider?: DIDProvider; // a DID provider (3ID provider initially)
    anchorService?: AnchorService;
    api?: CeramicApi; // the self reference to the Ceramic API
}

/**
 * Describes common doctype attributes
 */
abstract class Doctype extends EventEmitter {
    constructor(private _state: DocState, private _context: Context) {
        super()
    }

    get id(): string {
        return DoctypeUtils.createDocId(this.state.log[0])
    }

    get doctype(): string {
        return this._state.doctype
    }

    get content(): any {
        return cloneDeep(this.state.content)
    }

    get owners(): Array<string> {
        return cloneDeep(this.state.owners)
    }

    get state(): DocState {
        return cloneDeep(this._state)
    }

    set state(state: DocState) {
        this._state = state
    }

    get context(): Context {
        return this._context
    }

    get head(): CID {
        return this.state.log[this.state.log.length - 1]
    }

    /**
     * Makes a change on an existing document
     * @param params - Change parameters
     * @param opts - Initialisation options
     */
    abstract change(params: Record<string, any>, opts?: InitOpts): Promise<void>;
}

/**
 * Doctype decorator
 * @constructor
 */
function DoctypeStatic<T>() {
    return <U extends T>(constructor: U): any => { constructor };
}

/**
 * Doctype static signatures
 */
interface DoctypeConstructor {
    /**
     * Constructor signature
     * @param state - Doctype state
     */
    new (state: DocState): Doctype;

    /**
     * Makes genesis record
     * @param params - Create parameters
     * @param context - Ceramic context
     * @param opts - Initialization options
     */
    makeGenesis(params: Record<string, any>, context?: Context, opts?: InitOpts): Promise<Record<string, any>>;
}

interface DoctypeHandler<T extends Doctype> {
    /**
     * The string name of the doctype
     */
    name: string;

    /**
     * The doctype class
     */
    doctype: DoctypeConstructor;

    /**
     * Applies record to the document (genesis|signed|anchored)
     * @param record - Record intance
     * @param cid - Record CID
     * @param context - Ceramic context
     * @param state - Document state
     */
    applyRecord(record: any, cid: CID, context: Context, state?: DocState): Promise<DocState>;

}

CeramicApi

The CeramicApi is implemented by both ceramic-core and ceramic-http-client thus providing the same api for both remote clients and node instances.

interface PinApi {
    add(docId: string): Promise<void>;
    rm(docId: string): Promise<void>;
    ls(docId?: string): Promise<AsyncIterable<string>>;
}

interface JsonRpc2Response {
    'id': string;
    'json-rpc': string;
    'result': object;
}

interface DIDProvider {
    send(jsonReq: object): JsonRpc2Response;
}

interface CeramicApi {
    pin: PinApi;
    ipfs: Ipfs.Ipfs;

    addDoctype<T extends Doctype>(doctypeHandler: DoctypeHandler<T>): void;
    createDocument<T extends Doctype>(doctype: string, params: object, opts?: InitOpts): Promise<T>;
    createDocumentFromGenesis<T extends Doctype>(genesis: any, opts?: InitOpts): Promise<T>;
    loadDocument<T extends Doctype>(docId: string, opts?: InitOpts): Promise<T>;
    applyRecord<T extends Doctype>(docId: string, record: object, opts?: InitOpts): Promise<T>;
    setDIDProvider (provider: DIDProvider): Promise<void>;
    close(): Promise<void>; // gracefully close the ceramic instance
}

Rationale

Standardising the api of Ceramic clients allows developers to have the same expectations regardless of how they are interacting with Ceramic. The standardisation of the Doctype interface also makes it easier for developers to add their own doctypes without having to modify the ceramic code base.

Implementation

Implementation will take place in js-ceramic.

Security Considerations

By allowing signing to happen client side in both ceramic-core and ceramic-http-client we can allow the users to always be in corntrol of their keys. When a user is interacting with the http client they can simply sign the data of the update record and the signed data can be passed over the http api to a cermic node in order to be applied to the document.

Copyright

Copyright and related rights waived via CC0.

This has been replaced by a new version of the same proposal. Here is the new Tile Doctype (CIP-8).

cip: 18
title: Connections Index
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Draft
category: Standards
type: RFC
created: 2020-05-22
requires: Tile Doctype (CIP-8), StringMap (CIP-9)

Simple Summary

Connections Index simply stores links to other documents that contain various aspects of a DID's social graph.

Abstract

Connections are an important aspect of one's identity and can take many forms such as follows lists, friends, contacts, family, etc. In a user-centric model, this information should be controlled by a user and portable across applications. This eliminates the need for users to rebuild their entire social graph on every platform that they use.

Connections Index provides a standard interface for discovering and routing to various documents that represent different aspects of a DID's complete social graph. Connections Index does not store the social graph information itself, but rather stores pointers to documents that do.

Connections Index is a subdirectory of the Identity Index (IDX) (CIP-11) and is often linked from the Root Index (CIP-12).

Motivation

• Connections are a critical aspect of one's identity
• Connections should exist independent from any platform
• There will be many different types of connections lists
• There should be a standard interface for applications to locate and query these connections lists

Specification

The Connections Index specification consists of a doctype, schema, table, and tags.

Doctype

Connections Index is a Tile Doctype (CIP-8).

Schema

Connections Index utilizes the String Map (CIP-9) schema, which simply stores a list of strings which map to other strings. In this context, the key string should contain the name of the social graph resource, and the value string should contain its location. A reference to this schema should be included in your Connections Index document when it is created.

Table

The Connections Index Table (to be created at a later time) contains the standard set of properties that may be contained in any given Connections Index. New properties can be added to the table by following the steps below. Additional properties not found in this table may be stored in any Connections Index, however they may be less interoperable since others may not know what they represent. Here are some common examples of properties stored in the Connections Index:

• follows: the DocId of a Follows List (CIP-N), which contains a list of DIDs that this DID is following
• contacts: the DocId of a Contacts List (CIP-N), which contains a list of contacts
• family: the DocId of a Family List, which contains a list of family members

How to add a new property to the Connections Index Table

1. Choose a unique, descriptive property name.
2. Add a description for your property.
3. Submit a PR to the CIP repository updating the Connections Index Table with your property.
4. Mention the authors of this CIP in the comments of your PR.

Tags

When creating a Connections Index document, add ConnectionsIndex to the tags field.

Example

An example Connections Index document.

"doctype": "tile"
"schema": "<insert canonical schema for String Map>"
"tags": ["ConnectionsIndex", "StringMap"]
"content": {
  "follows": "ceramic://bafyljsdf1...",
  "contacts": "ceramic://bafysdfoijwe2...",
  "family": "ceramic://bafysdfoijwe3..."
}

Suggested Usage

Root Index: Connections Index provides a directory of connections lists, however connections are just one type of resource that can be associated with a DID. The Root Index (CIP-12) provides a top-level root directory for resources, and can contain a property called connections which stores a link to a Connections Index document. The recommended path for mapping from a DID to the Connections Index is: DID/Root Index/Connections Index.

Rationale

Extensibility & Flexibility: It is impossible to predict all of the types of connections that need to be associated with any particular DID. Therefore Connections Index was designed to be an infinitely extensible directory that can support any number of connections lists.

Decentralization & Trust: Connections directory information is data that needs to be globally-available, censorship-resistant, and live permissionlessly in the public domain (not on any single server). Additionally this information should be owned by a DID and will need to be updated from time to time. These requirements make Ceramic the most appropriate platform for publishing this content.

Implementation

String Map Schema: Find the String Map Schema here.

Connections Index Table: Find the table containing standard Connections Index properties here (to be updated when available).

Libraries: Not yet available.

Copyright

Copyright and related rights waived via CC0.

cip: 9
title: String Map
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Draft
category: Standards
type: RFC
created: 2020-07-13
requires: Tile Doctype (CIP-8)

Simple Summary

The String Map defines a document that stores mappings from one string to another string.

Abstract

For many use cases of Ceramic it is desirable to create a document that simply stores a list of mappings from a property to a value where both the property and value are strings.

Motivation

Such a standard would be helpful in defining a basic schema that many in the Ceramic ecosystem can use when creating documents.

Specification

The String Map specification consists of a doctype, a schema, and a tag.

Doctype

The String Map schema is defined in a tile doctype (CIP-N).

Schema

The String Map schema defines a document which maintains a list of strings that map to other strings. If this schema is used in a document, these rules will be enforced by the Ceramic protocol.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "StringMap",
  "type": "object",
  "additionalProperties": {
    "type": "string"
  }
}

Tags

When creating a document that conforms to the StringMap schema, add StringMap to the tags field.

Rationale

This proposal is fairly straightforward and no other design considerations were made.

Implementation

String Map Schema: This version of the String Map schema can be found at ceramic://bafy.../?version (will update after it is deployed).

Usage

When creating a new document that conforms to the String Map schema, you should include the schema version included above in the schema property and the StringMap tag in the tags property.

Security Considerations

None

Copyright

Copyright and related rights waived via CC0.

cip: 17
title: Services Index
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Draft
category: Standards
type: RFC
created: 2020-05-22
requires: Tile Doctype (CIP-8), StringMap (CIP-9)

Simple Summary

Services Index stores a list of documents which contain information about a DID's preferred services, such as notifications or backup.

Abstract

Add more detail here.

Services Index is a subdirectory of the Identity Index (IDX) (CIP-11) and is often linked from the Root Index (CIP-12).

Motivation

• Identity-centric services are an important aspect to the user-centric web, where users employ/permission specific services to act on their behalf and any application can make use of these services
• These services need to exist independent from any single application or platform
• There will be many different types of services lists
• There should be a standard interface for apps to discover services lists so they can locate and interact with these services

Specification

The Services Index specification consists of a doctype, schema, table, and tags.

Doctype

Services Index is a Tile Doctype (CIP-8).

Schema

Services Index utilizes the String Map (CIP-9) schema, which simply stores a list of strings which map to other strings. In this context, the key string should represent the category of service, and the value string should represent a document that stores a list of services within that category. A reference to this schema should be included in your Services Index document when it is created.

Table

The Services Index Table (to be created at a later time) contains the standard set of properties that may be contained in any given Services Index. New properties can be added to the table by following the steps below. Additional properties not found in this table may be stored in any Services Index, however they may be less interoperable since others may not know what they represent. Here are some common examples of properties stored in the Services Index:

• notifications: the DocId of a Notifications Service List, which contains a list of notification services used by this DID
• backup: the DocId of a Backup Service List, which contains a list of data backup services used by this DID
• consent: the DocId of a Consent Services List, which contains a list of privacy management services used by this DID

How to add a new property to the Services Index Table

1. Choose a unique, descriptive property name.
2. Add a description for your property.
3. Submit a PR to the CIP repository updating the Services Index Table with your property.
4. Mention the authors of this CIP in the comments of your PR.

Tags

When creating a Services Index document, add ServicesIndex to the tags field.

Example

An example Services Index document.

"doctype": "tile"
"schema": "<insert canonical schema for String Map>"
"tags": ["ServicesIndex", "StringMap"]
"content": {
  "notifications": "ceramic://bafyljsdf1...",
  "backup": "ceramic://bafysdfoijwe2...",
  "consent": "ceramic://bafysdfoijwe3..."
}

Suggested Usage

Root Index: Services Index provides a directory of services lists, however services are just one type of resource that can be associated with a DID. The Root Index (CIP-12) provides a top-level root directory for resources, and can contain a property called services which stores a link to a Services Index document. The recommended path for mapping from a DID to the Services Index is: DID/Root Index/Services Index.

Rationale

Extensibility & Flexibility: It is impossible to predict all of the types of services that need to be associated with any particular DID. Therefore Services Index was designed to be an infinitely extensible directory that can support any number of services lists.

Decentralization & Trust: Services directory information is data that needs to be globally-available, censorship-resistant, and live permissionlessly in the public domain (not on any single server). Additionally this information should be owned by a DID and will need to be updated from time to time. These requirements make Ceramic the most appropriate platform for publishing this content.

Implementation

String Map Schema: Find the String Map Schema here.

Services Index Table: Find the table containing standard Services Index properties here (to be updated when available).

Libraries: Not yet available.

Copyright

Copyright and related rights waived via CC0.

cip: 26
title: DID Array
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Draft
category: Standards
type: RFC
created: 21-07-2020
requires: Tile Doctype (CIP-8)

Simple Summary

DID Array defines the format of a document that stores an array of DIDs.

Abstract

For many use cases of Ceramic it is desirable to create a document that simply stores a list of DIDs. This could be useful for things like social graphs (follows), user lists, member lists, and more.

Motivation

Such a standard would be helpful in defining a reusable schema that many in the Ceramic ecosystem can use when creating documents.

Specification

The DID Array specification consists of a doctype, a schema, and a tag.

Doctype

DID Array is stored in a Tile Doctype (CIP-8).

Schema

The DID Array schema defines a document which maintains a list of DIDs. If this schema is used in a document, these rules will be enforced by the Ceramic protocol.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "array",
  "title": "DIDArray",
  "items": {
    "$ref": "#/definitions/DID"
  },
  "definitions": {
    "DID": {
      "type": "string",
      "pattern": "^did:.+:.+"
    }
  }
}

Tags

When creating a document that conforms to the DID Array schema, add DIDArray to the tags field.

Rationale

This proposal is fairly straightforward and no other design considerations were made.

Implementation

DID Array Schema: This version of the DID Array schema can be found at ceramic://bafy.../?version (TODO: update after deployment)

Usage

When creating a new document that conforms to the DID Array schema, you should include the schema version included above in the schema property and the DIDArray tag in the tags property.

Copyright

Copyright and related rights waived via CC0.

cip: 
title: Advanced Queries
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: Interface
created: 2020-05-22
requires:
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

Advanced queries allows users to query along known paths of linked documents without needing to query one at a time.

cip: 
title: Follows List
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-05-22
requires: Tile Doctype (CIP-8)
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

Follows List contains a list of DIDs that a DID is following.

Abstract

The follows list aims to provide permissionless, platform-agnostic storage for a list of DIDs followed by this DID.

Motivation

Follows are often a critical aspect of identity on many digital platforms. The follows list provides a unified social graph that can be shared across platforms, eliminating the need for users to redundantly replicate the same information on each new platform.

Specification

The Follows List specification consists of a doctype, schema, and tags.

Doctype

Follows List is a Tile Doctype (CIP-8).

Schema

The Follows List utilizes the DID Array schema, which simply stores an array of DIDs. A reference to this schema should be included in your Follows List document when it is created.

Tags

When creating a Follows List document, add FollowsList to the tags field.

Example

An example Follows List document.

"doctype": "tile"
"schema": "<insert canonical schema for DID Array>"
"tags": ["FollowsList", "DIDArray"],
"content": {
  ["DID1","DID2","DID3",...]
}

This has been deprecated in favor of the more general Access Control Document.

cip: 
title: Work Profile
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-05-25
requires: Tile Doctype (CIP-8)
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

Work profile contains the work profile of a DID.

Abstract

Add better description.

Work Profile is usually linked from a Profiles Index (CIP-13) document.

Motivation

Specification

Work profile borrows many attribute names from the schema.org person schema.

name:

image:

description:

duns: The Dun & Bradstreet DUNS number for identifying an organization or business person.

workHistory: The DocId of a Work History document.

This has been deprecated, since it seems unnecessary to validate the format of schema documents.

cip: 
title: Education History
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-07-01
requires: Tile Doctype (CIP-8)
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time.

Simple Summary

Education History contains the education history of a DID.

Abstract

Add detailed description.

Education History is usually linked from an Education Profile.

Motivation

Education History is often considered an aspect of one's identity, and is particularly useful for certain purposes such as hiring and consideration for employment.

Specification

The Education History specification consists of a doctype, schema, and tags.

Doctype

Education History is a Tile Doctype (CIP-8).

Schema

The Education History document contains an array of objects that each contain the optional fields below.

institution: The institution of learning; a string (or should it be a DID?)

degree: The type of degree (i.e. Bachelors, BA); what should the format be, are there standards?

focus: The focus (i.e. major)

startDate: Start date; ISO (add link and number)

endDate: End date; ISO (add link and number)

proofs: An array of proofs

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "EducationHistory",
  "type": "array",
  "items": {
    "$ref": "#/definitions/Education"
  },
  "definitions": {
    "Education": {
      "type": "object",
      "properties": {
        "institution": {
          "type": "string",
          "title": "institution"
        },
        "degree": {
          "type": "string",
          "title": "degree"
        },
        "focus": {
          "type": "string",
          "title": "focus"
        },
        "startDate": {
          "type": "string",
          "format": "date",
          "title": "startDate"
        },
        "endDate": {
          "type": "string",
          "format": "date",
          "title": "endDate"
        },
        "proofs": {
          "type": "array",
          "title": "proofs",
          "items": {
            "type": "string"
          }
        }
      }
    }
  }
}

Tags

When creating an Education History document, include EducationHistory as a tag in the header.

Rationale

Backwards Compatibility

Implementation

Copyright

Copyright and related rights waived via CC0.

cip: 
title: Service Definition
author: Joel Thorstensson (@oed), Janko Simonovic (@simonovic86)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-05-22
requires:
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

Service Definition specifies a document which describes a service.

Abstract

A Service Definition document allows service providers to describe their microservice in a way that makes it easily discoverable and consumable by others. This is especially useful when thinking about services in the context of a user-centric web, where applications may need to interact with various services preferred by a user or that manage their data without having pre-existing relationships with those service providers.

Motivation

There is a need to improve service discoverability.

As the number of microservices and APIs on the web continues to increase at an exponential rate, discoverability becomes a challenge. By creating a service definition for your service, it instantly becomes publicly discoverable and searchable by everyone on the internet.

There is a need to decouple service definitions and endpoints from servers.

When an application does not know which services it may need to rely on to service a user prior to the user arriving at their site, that application needs a simple, permissionless way to dynamically discover the API definition and endpoint of the service they need to interact with. For this reason, service definitions need to be stored in the public domain where they can be seen by anyone at anytime, without needing to create an account or read the docs.

There is a need to eliminate account signups and API keys.

Modern development is trending in the direction of applications that don't manage a backend. Instead, developers are choosing to build lightweight frontends that rely on an ecosystem of composable backend services. Making things even more difficult, in the user-centric model of application development users may bring different services with them to an application, and the application needs to use those services to serve the user. It is infeasible for every application to create accounts with every single web service. For these reasons it is impossible to store an API key on a backend server to authenticate on behalf of a user.

There is a need to define access requirements, including payment.

When account signups and API keys are gone, how can services be authenticated and compensated? By creating service definitions, service providers can specify the access requirements for their service, which may include an authentication signature from a DID, a micropayment, or both. This allows services to serve a wide range of users that aren't direct customers without adding the friction of account signups.

There is a need to unlock interoperability.

Together the needs above all hint towards a future of the web where applications and services need to establish and dissolve fluid, dynamic relationships between each other, often for single interactions. It becomes increasingly important for services to make themselves as interoperable as possible to applications and other services so that they can take advantage of this new paradigm.

cip: 25
title: DID Provider
author: Paul LeCam (@PaulLeCam), Joel Thorstensson (@oed)
status: Idea
category: Standards
type: Interface
created: 2020-05-22
requires:

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

DID Provider describes a standard JSON RPC interface for interacting with DIDs.

cip: 
title: Contacts List
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-05-22
requires:
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

Contacts List stores a list of contacts for a DID.

Discussion for CIP-11: Identity Index (IDX)

See PR #65 for the updated spec.

cip: 
title: Work History
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-06-15
requires: Tile Doctype (CIP-8)
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time.

Simple Summary

Work History contains the employment history for a DID.

Abstract

Add description.

Work History is usually linked from a Work Profile document.

Motivation

Specification

The Work History specification consists of a doctype, schema, and tags.

Doctype

Work History is a Tile Doctype (CIP-8).

Schema

A Work History document stores an array of objects that represent jobs or employment. Each object consists of the optional properties below.

Work History borrows many attribute names from the schema.org person schema.

worksFor: An employer; a string. (Or should this be a DID?)

jobTitle: A job title (for example, Financial Manager); a string.

jobDescription: A description of the job; a string.

startDate: Start date; ISO (Add ISO number and link)

endDate: End data; ISO (Add ISO number and link)

proofs: An array of proofs that prove this employment claim to be true.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "array",
  "title": "WorkHistory",
  "items": {
    "$ref": "#/definitions/Work"
  },
  "definitions": {
    "Work": {
      "type": "object",
      "properties": {
        "worksFor": {
          "type": "string",
          "title": "worksFor"
        },
        "jobTitle": {
          "type": "string",
          "title": "jobTitle"
        },
        "jobDescription": {
          "type": "string",
          "title": "jobDescription"
        },
        "startDate": {
          "type": "string",
          "format": "date",
          "title": "startDate"
        },
        "endDate": {
          "type": "string",
          "format": "date",
          "title": "endDate"
        },
        "proofs": {
          "type": "array",
          "title": "proofs",
          "items": {
            "type": "string"
          }
        }
      }
    }
  }
}

Tags

When creating a Work History document, add WorkHistory to the tags field.

Example

Implementations

Copyright

Copyright and related rights waived via CC0.

cip: 
title: Education Profile
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-05-26
requires: Tile Doctype (CIP-8)
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time.

Simple Summary

Education Profile contains the education profile of a DID.

Abstract

Add description.

Education Profile is usually linked from a Profiles Index (CIP-13).

Motivation

Specification

The Education Profile specification consists of a doctype, schema, and tags.

Doctype

Education Profile is a Tile Doctype (CIP-8).

Schema

name: A string that represents a name.

image: An CID (IPFS hash) of an image.

description: A string that serves as a description for the DID.

history: The DocId of an Education History document.

Tags

When creating an Education Profile document, add EducationProfile to the tags field.

Example

Discussion for CIP-20
See PR for most up to date version: #68

cip: 
title: Anchor Service
author: Joel Thorstensson (@oed), Janko Simonovic (@simonovic86)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-05-22
requires:
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

An anchor service is a layer 2 service used by a Ceramic node to batch multiple signed records (document updates) and anchor them into a blockchain using a single transaction.

Abstract

Anchor services are not explicitly required by the protocol and users can always directly anchor their own transactions in a blockchain one at a time.

Motivation

Anchor services will play a crucial role in the Ceramic network.

• Increased Scale:

• Lower Cost:

• Better User Experience:

• Metadata for Indexing: Anchor services add additional metadata and information to anchors that makes it easier for indexing services to know which documents have been updated via an anchor.

Specification

Usage

Security Considerations

Implementations

• ceramic-anchor-service: An implementation of this specification that anchors batches of signed records on the Ethereum blockchain.

Deprecated and closed

cip: 3
title: Ceramic Ecosystem Alliance (CEA)
author: Michael Sena (@michaelsena)
discussions-to:
status: Final
category: Meta
type:
created: 2020-06-14
requires:
replaces: 

Simple Summary

The Ceramic Ecosystem Alliance (CEA) allows members to self-organize into working groups to discuss important topics related to Ceramic and produce outputs (normally in the form of CIPs).

Abstract

The CEA IS a grassroots network of Ceramic collaborators. It was created as a way for community members to self-organize into working groups to collaboratively discuss important topics related to Ceramic (such as governance, standards, use cases).

The CEA IS NOT a replacement for Ceramic Core Calls, including Core Community Calls where the broader community convenes to learn more about Ceramic, and Core Devs Calls where Ceramic developers discuss network upgrades. The CEA also is not a replacement for CIPs the process by which the community formally proposes standards or improvements to Ceramic. Rather, the CEA serves as a focused vehicle for interested parties to zoom in on important issues, organize into topic-based working groups, and share outcomes amongst the group. A working group will often produce one or more CIPs.

Motivation

Grassroots, Topic-Based Collaboration: CIPs are the method for proposing improvements to Ceramic, but often times community members want to collaborate more closely on those issues. The CEA provides a structure for closer topic-based collaboration to happen.

Specification

Location

The structure for the CEA should exist within the Ceramic Network github organization, in its own repo. http://github.com/ceramicnetwork/CEA

Participant Structure

The CEA has three levels of participant structure:

Meetings

All meetings for the CEA and Working Groups will be added to a CEA Calendar. All members of the CEA have access to this calendar and can join any meeting.

CEA Meetings

The entire CEA gathers every two weeks for a meeting (attendance is optional). In this meeting, members:

• Share progress from existing working groups
• Propose the creation of new working groups

Since CEA meetings are primarily built around sharing progress from working groups, at least 1 member from each active working group is expected to attend.

Working Group Meetings

CEA members self-organize into topic-based initiatives, called working groups. Individual working groups create their own charter, decide their own meeting schedule, and get their own designated channel in the Ceramic discord server. Typically, working groups meet every two weeks so they have something to share out at the next bi-weekly CEA meeting. Notes from working group meetings are helpful to keep the rest of the CEA aligned. Use the CEA meetings notes template to take good meeting notes.

How to join the CEA

1. Submit a Pull Request to the CEA repository adding yourself to the members table in the README.

2. Fill out this form.

Once a steward has confirmed you have completed the previous two steps, they will merge your PR and send you a welcome email containing your invitations to the CEA Call Calendar and Discord.

How to form a new working group

1. Join the CEA.
2. Create a charter for your working group.
3. Submit a Pull Request to the CEA repository adding your working group and charter.
4. Propose your working group at the next CEA meeting. If approved, your PR will be merged, you will get a designated channel in the Ceramic discord, and your working group meeting schedule (specified in the charter) will be added to the CEA calendar.
5. Recruit participants for your working group.

Stewards

• Michael Sena (@michaelsena)
• Joel Torstensson (@oed)
• Danny Zuckerman (@dazuck)

Implementation

• CEA Repository: http://github.com/ceramicnetwork/CEA
• Join the CEA: https://github.com/ceramicnetwork/CEA/blob/master/README.md#join-the-cea

Copyright

Copyright and related rights waived via CC0.

Title: User-Centric Service Standard
Author: Michael Sena [email protected], Joel Thorstensson [email protected]
Type: Standards
Category: CRC
Status: Idea
Created: 2020-05-26

Simple Summary

The User-Centric Service Standard (UCSS) is a way to provide DIDs with user-centric web services, such as notifications.

Abstract

Motivation

Definitions

did:

account:

services:

service:

Specification

V1

cip: 
title: Family List
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-05-25
requires: Tile Doctype (CIP-8)
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

Family List contains information about a DID's family members, such as siblings, spouse, children, etc.

Abstract

Insert better description.

The Family List is often linked from a Connections Index (CIP-18.

Motivation

Family is a common aspect of one's identity.

Specification

The Family List specification consists of a doctype, schema, and tags.

Doctype

The Family List is a Tile Doctype (CIP-8).

Schema

Family List borrows many attribute names from the schema.org person schema.

siblings: An array of DIDs for the DID's siblings.

spouses: An array of DIDs for the DID's spouse(s).

children: An array of DIDs for the DID's children.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "siblings": {
      "$ref": "#/definitions/DIDArray"
    },
    "spouses": {
      "$ref": "#/definitions/DIDArray"
    },
    "children": {
      "$ref": "#/definitions/DIDArray"
    }
  },
  "definitions": {
    "DID": {
      "type": "string",
      "pattern": "^did:.+:.+"
    },
    "DIDArray": {
      "type": "array",
      "items": {
        "$ref": "#/definitions/DID"
      }
    }
  }
}

Tags

When creating a Family List document, add FamilyList to the tags field.

Example

cip: 14
title: Accounts Index
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Draft
category: Standards
type: RFC
created: 2020-05-22
requires: Tile Doctype (CIP-8), DocId Map (CIP-10)

Simple Summary

Accounts Index stores a list of documents that contain information about a DID's publicly linked accounts.

Abstract

Oftentimes users want to publicly associate various identities from external services to their DID in order to prove to others that all are owned by the same person or entity. These identities can include blockchain accounts and/or contracts, other forms of cryptographic accounts, social accounts such as Twitter or Github, domain names, DIDs and more.

Collectively these account associations can function as a powerful form of identity verification for DIDs and can serve to add trust to our digital interactions since counter-parties can be sure, with cryptographic proof, that the entity they are interacting with is the authentic owner of another well-known public account. This aspect allows implicit or explicit reputation accrued on the linked account to be transferred to the DID, and by extension, all the other accounts linked to the DID.

Accounts Index is a directory of documents that each contain specific aspects of a DID's linked account universe. Because of this, Accounts Index functions as a discovery and routing mechanism to those verifications. By standardizing how one or more types of linked accounts are associated to a DID, the Accounts Index simplifies the process of integrating many different accounts with the same identity and provides a common interface for applications to use when querying or discovering those various accounts.

Accounts Index is a component of the Identity Index (IDX) (CIP-11) and is often linked from the Root Index (CIP-12). In turn, Accounts Index usually links to a Crypto Account Links (CIP-21) and/or a Social Account Links (CIP-22) document.

Motivation

Accounts Index aims to:

• Create a standard interface for adding and querying a DID's various linked accounts
• Afford developers the ability to lookup an account to resolve a DID, all other linked accounts, and other metadata
• Provide flexibility in adding new linked account types
• Offer decentralized Keybase-like functionality for DIDs

Specification

The Accounts Index specification includes a doctype, schema, table, and tag.

Doctype

Accounts Index is a Tile Doctype (CIP-8).

Schema

Accounts Index utilizes the DocId Map (CIP-10) schema, which simply stores a list of strings which map to Ceramic DocIds. In this case, Ceramic DocIds represent documents that store lists of linked accounts. A reference to this schema should be included in your Accounts Index document when it is created.

Table

The Accounts Index Table (coming soon) contains the standard set of properties that may be contained in any given Accounts Index document. New properties can be added to the table by following the steps below. Additional properties not found in this table may be stored in any Accounts Index, however they may be less interoperable since others may not know what they represent.

Here are some examples from the Accounts Index Table:

How to add a new property to the Accounts Index table

1. Choose a unique, descriptive property name.
2. Add a description for your property.
3. Submit a PR to the CIP repository updating the Accounts Index table with your property.
4. Mention the authors of this CIP in the comments of your PR.

Example

An example Accounts Index document.

"doctype": "tile"
"schema": "<insert canonical schema for DocId Map>"
"tags": ["AccountsIndex", "DocIdMap"],
"content": {
  "crypto": "ceramic://bafyljsdf1...",
  "social": "ceramic://bafysdfoijwe2..."
}

Suggested Usage

Root Index: Accounts Index provides an index of documents that store linked accounts. However accounts are just one type of resource that can be associated with a DID. The Root Index (CIP-12) provides a top-level directory of a DID's resources, and can contain a property called accounts which stores a link to the Accounts Index. The recommended path from a DID to the Accounts Index is: DID/Root Index/Accounts Index.

Content: It is recommended that the Accounts Index only be used to store mappings to documents that contain lists of similar account links. Examples of this would be linking to a Crypto Accounts Links and Social Accounts Links documents.

Rationale

Extensibility & Flexibility: It is impossible to predict all of the types of accounts that need to be associated with any particular DID. Therefore Accounts Index was designed to be infinitely extensible to support indexing many different kinds of linked account lists.

Decentralization & Trust: Linked account information is data that needs to be globally-available, cross-platform, censorship-resistant, and live permissionlessly in the public domain (not on any single server). Additionally this information should be owned by a DID and will need to be updated from time to time. These requirements make Ceramic the most appropriate platform for publishing this content.

Implementation

DocId Map Schema: Find the DocID Map (CIP-10) schema here.

Accounts Index Table: Find the table containing standard Account Index properties here (coming soon).

Libraries: Not yet available.

Copyright

Copyright and related rights waived via CC0.

cip: 15
title: Keychains Index
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Draft
category: Standards
type: RFC
created: 2020-05-22
requires: Tile Doctype (CIP-8), String Map (CIP-9)

Simple Summary

Keychains Index is a document that stores mappings to a DID's various keychains.

Abstract

Decentralized identifiers (DIDs) have a set of keys (i.e. management, signing, encryption, etc) that are controlled by a seed. However, sometimes it is desirable to use other keys for authenticating or performing other actions. Examples of this might include using crypto keys from various technologies, networks, or wallets to authenticate a DID.

Keychains Index defines an extensible directory of a DID's keychains. It does not store the key material itself, but rather stores pointers to documents which do. By standardizing how various keychains are associated to a DID, the Keychains Index expands how a DID can be controlled and the possibilities of what it can do.

Keychains Index is a subdirectory in the Identity Index (IDX) (CIP-11) and is often linked from the Root Index (CIP-12).

Motivation

Extended Capabilities Provided by Multiple Keychains: DIDs may need any number of keychains beyond just a basic seed to perform more specific functions related to various applications, platforms, encryption, or technology contexts.

DID Resilience and Improved Key Management: By associating one or more keychains to the DID which can perform actions such as authentication, the Keychains Index provides the foundation for improving key management for DIDs. Instead of only authenticating via seed, DIDs can be authenticated by any number of keys in an auth keychain. This adds resilience and anti-fragility to a DID, since as long as the user maintains control of one of their authentication keys they will remain in control of their DID. These authentication keys are usually crypto wallet keys, so therefore key management is delegated to every wallet that holds a user's keys.

Specification

The Keychains Index specification includes a doctype, schema, table, and tag.

Doctype

Keychains Index is a Tile Doctype (CIP-8).

Schema

Keychains Index utilizes the String Map (CIP-9) schema, which simply stores a list of strings which map to other strings. In this context, the key string is used to name the keychain and the value string is used to store the location of the keychain. A reference to this schema should be included in your Keychains Index document when it is created.

Table

The Keychains Index Table (coming soon) contains the standard set of properties that may be contained in any given Keychains Index. New properties can be added to the table by following the steps below. Additional properties not found in this table may be stored in any Keychains Index, however they may be less interoperable since others may not know what they represent. Here are some common examples of properties stored in the Keychains Index:

• auth: a link to an Auth Keychain (CIP-20), which contains authentication related data for a DID
• legacy3box: a link to a Legacy 3Box Keychain that is used to encrypt/decrypt data kept in 3Box data stores prior to (insert date of architecture migration)

How to add a new property to the Keychains Index Table

1. Choose a unique, descriptive property name.
2. Add a description for your property.
3. Submit a PR to the CIP repository updating the Keychains Index Table (coming soon) with your property.
4. Mention the authors of this CIP in the comments of your PR.

Tags

When creating a Keychains Index document, add KeychainsIndex to the tags field.

Example

An example Keychains Index document.

"doctype": "tile"
"schema": "<insert canonical schema for String Map>"
"tags": ["KeychainsIndex", "StringMap"]
"content": {
  "auth": "ceramic://bafyljsdf1...",
  "legacy3box": "ceramic://bafysdfoijwe2..."
}

Suggested Usage

Root Index: Keychains Index provides a directory of keychains, however keychains are just one type of resource that can be associated with a DID. The Root Index (CIP-12) provides a top-level root directory for resources, and can contain a property called keychains which stores a link to a Keychains Index. The recommended path from a DID to the Keychains Index is: DID/Root Index/Keychains Index.

Rationale

Extensibility & Flexibility: It is impossible to predict all of the types of keychains that will need to be associated with any particular DID. Therefore Keychains Index was created to function an infinitely extensible directory that can support any number of keychains.

Decentralization & Trust: Keychain directory information is data that needs to be globally-available, censorship-resistant, and live permissionlessly in the public domain (not on any single server). Additionally this information should be owned by a DID and will need to be updated from time to time. These requirements make Ceramic the most appropriate platform for publishing this content.

Implementation

String Map Schema: Find the String Map Schema here.

Keychains Index Table: Find the table containing standard Keychains Index properties here (coming soon).

Libraries: Not yet available.

Copyright

Copyright and related rights waived via CC0.

cip: 10
title: DocId Map
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Draft
category: Standards
type: RFC
created: 2020-07-13
requires: Tile Doctype (CIP-8)

Simple Summary

The DocId Map defines a document that stores mappings from strings to Ceramic DocIds.

Abstract

For many use cases of Ceramic it is desirable to create a document that simply stores a list of mappings from a property to a value where the property is a string and the value is a Ceramic DocId.

Motivation

Such a standard would be helpful in defining a basic schema that many in the Ceramic ecosystem can use when creating documents.

Specification

The DocId Map specification consists of a doctype, a schema, and a tag.

Doctype

The DocId Map is defined in a Tile Doctype (CIP-8).

Schema

The DocId Map schema defines a document which maintains a list of properties that must be strings and values that must be Ceramic docIds. These rules will be enforced by the Ceramic protocol.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "title": "DocIdMap",
  "additionalProperties": {
    "$ref": "#/definitions/CeramicDocId"
  },
  "definitions": {
    "CeramicDocId": {
      "type": "string",
      "pattern": "^ceramic://.+(\\?version=.+)?"
    }
  }
}

Tags

When creating a document that conforms to the DocId Map schema, add DocIdMap to the tags field.

Rationale

This proposal is fairly straightforward and no other design considerations were made.

Implementation

DocId Map Schema: This version of the DocId Map schema can be found at ceramic://bafy.../?version (will update after it is deployed)

Usage

When creating a new document that conforms to the DocId Map schema, you should include in the document header the schema version included above in the schema property and a DocIdMap tag in the tags property.

Security Considerations

None

Copyright

Copyright and related rights waived via CC0.

cip: 
title: Access Control Document
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-07-01
requires: Tile Doctype (CIP-8)
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time.

Simple Summary

The Access Control Document provides an access control module that can be used to add privacy features to any Ceramic document.

Abstract

Abstract goes here.

Motivation

Motivation goes here.

Specification

Specification goes here.

Rationale

Rationale goes here.

Backwards Compatibility

Backwards compatibility goes here.

Implementation

Implementation goes here.

Security Considerations

Security considerations go here.

Copyright

Copyright and related rights waived via CC0.

cip: 28
title: Collection Definition
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed), Paul LeCam (@PaulLeCam)
status: Idea
category: Standards
type: RFC
created: 2020-05-22
requires: Tile Doctype (CIP-8)

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

This CIP specifies a Collection Definition which is a document created by a developer to describe the generic data model for their application's user data.

Abstract

Collection Definitions are created by developers to describe the user data model of their application in a public and transparent way. Collection Definitions include collections of stores which conform to store types, schemas, and access controllers.

Collection Definitions are complimentary to Collection References (CIP-29), which actually contain user-specific information about the generic stores described in the Collection Definition. Links to both of these documents are stored in a DID's Collections Index (CIP-16), providing a way for user data to be made interoperable across application and platforms.

Motivation

The user-centric model of application development aims to make data created by one application consumable by another. Achieving this depends on allowing application developers to publicly describe their data model in a way that can be universally access by other applications.

Decouple schemas from data stores:

Make schemas publicly discoverable:

Enable cross-application data portability:

Enable convergence around schemas:

Specification

Schema

store: A description of the data store. (i.e. Textile, OrbitDB, Ethereum, Ceramic)

storeType: The type of data store. (i.e. thread, key-value, feed, registry, transaction, doctype)

accessController: The access control system used by the store.

schema: The schema used by the store.

Discussion for CIP-21.
See PR for up to date spec: #67

Title: Claims Document
Author: Michael Sena [email protected], Joel Thorstensson [email protected]
Type: Standards
Category: CRC
Status: Idea
Created: 2020-05-23

Simple Summary

The claims document stores links to various claim documents (CIP-) issued to the DID. The claims document simply acts as a routing mechanism to those other sources of verifiable information about an identity.

The claims document is a component of the Identity Standard (IS) (CRC-), and is often linked from an account document (CRC-).

Abstract

The claims document provides a flexible way to route to various claims issued by others about the DID, wherever they exist. It allows a DID to link to third-party claims that represent important aspects of their identity such as identity verifications, Oauth account verifications (Twitter, Github, Discord, Discourse, etc.), anti-sybil ratings, reputation scores, experience points, and more.

Motivation

Claims are an important aspect to an identity since they represent verifiable statements made by one party about another. Inevitably, these claims will exist in many different locations from Ceramic documents to servers. The claims document aims to provide a centralized place to store links to all of these various claims, making them easily discoverable and consumable by others.

Definitions

Specification

The claims document is stored in a Ceramic tile (CIP-).

The current claims document schema can be found at ceramic://bafy...

V1

Version 1 of the claims document schema can be found at ceramic://bafy.../?bafy...

Schema

{
    "$schema": "http://json-schema.org/draft-06/schema#",
    "type": "array",
    "items": {
        "type": "string"
    },
    "definitions": {}
}

Example

[<JWT>, <JWT>]

This has been deprecated because it is no longer needed.

cip: 13
title: Profiles Index
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Draft
category: Standards
type: RFC
created: 2020-05-22
requires: Tile Doctype (CIP-8), String Map (CIP-9)

Simple Summary

Profiles Index is a document that stores an index of a DID's profiles.

Abstract

For DIDs to be usable in the context of consumer applications they often need to support public metadata such as profiles. Over time users (or applications) may desire to create multiple profiles (i.e. personas). Examples of this might include a basic profile, work profile, education profile, gaming profile, etc. Without a standardized way for DID's to associate multiple profiles to their identity, there would be no single index for apps to query when resolving these various profiles, and users would be forced to use only one profile everywhere.

Profiles Index is an extensible directory that stores links to a DID's profiles. It does not store profile data, but rather stores links to profile data. By standardizing how one or more profiles are associated to a DID, Profiles Index simplifies the process of managing multiple profiles for an identity and enables applications to have a common interface for discovering and interacting with those various profiles.

Profiles Index is a subdirectory in the Identity Index (IDX) (CIP-11) and is often linked from the Root Index (CIP-12).

Motivation

A Core Piece of Identity: Profiles are often most associated with identity, and the Profiles Index allows DIDs to build an index of one or more profiles.

Future-proof & Extensibility of Multiple Profiles: Even if DID's only desire to support one basic profile in the beginning, using the Profiles Index allows for future extensibility. Adding new profiles just requires adding them to the index.

Standardization & Interoperability: By defining a common interface for creating an index of profiles, Profiles Index enables any application to discover and interact with the profile of their choice.

Specification

The Profiles Index specification includes a doctype, schema, table, and tag.

Doctype

Profiles Index is a Tile Doctype (CIP-8).

Schema

Profiles Index utilizes the String Map (CIP-9) schema, which simply stores a list of strings which map to other strings. In this context the key string is used to name the profile, while the value string is used to store the location of the profile. A reference to this schema should be included in your Profiles Index document when it is created.

Table

The Profiles Index Table contains the standard set of properties that may be contained in any given Profiles Index. New properties can be added to the table by following the steps below. Additional properties not found in this table may be stored in any Profiles Index, however they may be less interoperable since others may not know what they represent. Here are some common examples of properties stored in the Profiles Index:

• basic: a link to a Basic Profile (CIP-19), which contains general profile information for a DID
• work: a link to a Work Profile, which contains work-related profile information for a DID
• education: a link to an Education Profile, which contains education-related profile information for a DID
• gaming: a link to a Gaming Profile, which contains gaming-related profile information for a DID

How to add a new property to the Profiles Index Table

1. Choose a unique, descriptive property name.
2. Add a description for your property.
3. Submit a PR to the CIP repository updating the Profiles Index Table with your property.
4. Mention the authors of this CIP in the comments of your PR.

Tags

When creating a Profiles Index document, add ProfilesIndex to the tags field.

Example

An example Profiles Index document.

"doctype": "tile"
"schema": "<insert canonical schema for String Map>"
"tags": ["ProfilesIndex", "StringMap"]
"content": {
  "basic": "ceramic://bafyljsdf1...",
  "work": "ceramic://bafysdfoijwe2...",
  "education": "ceramic://bafysdfoijwe3...",
  "gaming": "ceramic://bafysdfoijwe4..."
}

Suggested Usage

Root Index: Profiles Index provides a directory of profiles, however profiles are just one type of resource that can be associated with a DID. The Root Index (CIP-12) provides a top-level root directory for resources, and can contain a property called profiles which stores a link to a Profiles Index document. The recommended configuration for mapping from a DID to the Profiles Index is: DID/Root Index/Profiles Index.

Rationale

Extensibility & Flexibility: It is impossible to predict all of the types of profiles that need to be associated with any particular DID. Therefore Profiles Index was designed to be an infinitely extensible directory that can support any number of profiles.

Decentralization & Trust: Profile directory information is data that needs to be globally-available, censorship-resistant, and live permissionlessly in the public domain (not on any single server). Additionally this information should be owned by a DID and will need to be updated from time to time. These requirements make Ceramic the most appropriate platform for publishing this content.

Implementation

String Map Schema: Find the String Map Schema here.

Profiles Index Table: Find the table containing standard Profiles Index properties here.

Libraries: Not yet available.

Copyright

Copyright and related rights waived via CC0.

cip: 29
title: Collection Reference
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Idea
category: Standards
type: RFC
created: 2020-05-22
requires: Tile Doctype (CIP-29)

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

This CIP describes a Collection Reference, which contains user-specific information about the data stores defined in a given Collection Definition (CIP-28).

Abstract

The Collection Reference contains user-specific information about data stores defined in a given Collection Definition (CIP-28). The Collection Reference stores things like unique storeID, host, and more that allow third-parties to locate and interact with the user's data. This document is created and updated as the user interacts with the application to which it applies.

Collection References are complimentary to Collection Definitions (CIP-28), which describe the generic data model of data stores referenced in a Collection Reference. Links to both of these documents are stored in a DID's Collections Index (CIP-16), providing a way for user data to be made interoperable across application and platforms.

Motivation

Specification

Schema

The Collection Reference stores a collectionDef as a global value, and then stores an array of objects which each include reference, storeId, host, and applications.

collectionDef: The DocId of the Collection Definition (CIP-28) to which this Collection Reference applies.

reference: A pointer to a specific entry in the Collection Definition that is possessed by this DID.

storeId: A unique identifier for the user's store. Depending on storeType, this can be the unique address of a peer-to-peer database, an entry in a registry, the ID/hash of a transaction, or the DocId of a Ceramic document.

host: A pointer to a location where the data store is hosted. This can be a centralized service or a decentralized, peer-to-peer network.

applications: A list of applications that have been granted access to the data store.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "title": "CollectionReference",
  "additionalProperties": false,
  "required": [
    "collectionRef",
    "references"
  ],
  "properties": {
    "collectionRef": {
      "$ref": "#/definitions/CeramicDocId"
    },
    "references": {
      "type": "array",
      "items": {
        "$ref": "#/definitions/CollectionRef"
      }
    }
  },
  "definitions": {
    "CeramicDocId": {
      "type": "string",
      "pattern": "^ceramic://.+(\\?version=.+)?"
    },
    "CollectionRef": {
      "type": "object",
      "required": [
        "reference",
        "storeId",
        "host",
        "applications"
      ],
      "properties": {
        "reference": {
          "type": "string",
          "title": "reference"
        },
        "storeId": {
          "type": "string",
          "title": "storeId"
        },
        "host": {
          "type": "string",
          "title": "host"
        },
        "applications": {
          "type": "array",
          "title": "applications",
          "items": {
            "type": "string"
          }
        }
      }
    }
  }
}

Usage

Encryption:

Data Interoperability Protocol (DIP):

cip: 22
title: Social Account Links
author: Michael Sena (http://github.com/michaelsena), Joel Thorstensson (http://github.com/oed)
status: Draft
category: Standards
type: RFC
created: 2020-06-15
requires: Tile Doctype (CIP-8), Linked Accounts Array (CIP-23)

Simple Summary

Social Account Links stores a list of a DID's linked social accounts.

Abstract

Oftentimes users may want to publicly associate various identities from social applications to their DID in order to prove to others that all are owned by the same person or entity. This could include Twitter, Github, Discord, Matrix and other similar services. Collectively these account associations can function as a powerful form of identity verification and reputation for DIDs and can serve to add trust to our digital interactions since counter-parties can be sure, with cryptographic proof, that the entity they are interacting with is the authentic owner of another well-known public account.

The Social Account Links document contains a list of a DID's social accounts and links to their proofs. Usually these proofs are issued by third-party account verification services as Verifiable Claim documents (TODO: add link once CIP is written). By standardizing how one or more social accounts are linked to a DID, the Social Account Links document enables applications to have a single, common interface to use for discovering and interacting with those accounts.

The Social Account Links document is usually linked to from an Accounts Index (CIP-14).

If you want to link other types of accounts to your DID such as crypto accounts, domain names and more, check out the Accounts Index.

Motivation

This specification aims to provide:

• The ability to link a DID to one or more social accounts
• A standard interface for interacting with a DID's linked social accounts
• Improved identity verification and reputation for DIDs through links to social accounts with existing reputation
• A single, predicable location and schema for verifications
• Decentralized Keybase-like functionality for DIDs

Specification

The Social Account Links specification consists of a doctype, schema, and tags.

Doctype

Social Account Links is a Tile Doctype (CIP-8).

Schema

Social Account Links utilizes the Linked Accounts Array (CIP-23) schema, which simply stores an array of JSON objects that are formatted to represent linked accounts. Although the Linked Accounts Array schema can store various types of linked accounts, for the scope of this document you should only store social account links. A reference to this schema should be included in your Social Account Links document when it is created.

Tags

When creating a new Social Account Links document, add SocialAccountLinks as a tag in the document header.

Example

An example Social Account Links document that includes a Twitter, Github, and Matrix account.

(to be updated)

"doctype": "tile"
"schema": "<insert canonical schema and current version for Linked Accounts Array>"
"tags": ["SocialAccountLinks", "LinkedAccountsArray"]
"content": {
        
"protocol": "https"
"host": "https://twitter.com"
"id": "https://twitter.com/marysmith"
"claim": "https://twitter.com/marysmith/status/1274020265417076736"             // ID of tweet containing the user's DID
"attestations": ["ceramic://bafy123...", "ceramic://bafy456..."]

"protocol": "https"
"host": "https://github.com"
"id": "https://github.com/marysmith"
"claim": "https://gist.github.com/marysmith/5c48debdb7089b3c8f86cca31739572c"   // ID of Gist containing the user's DID
"attestations": ["ceramic://bafy123..."]

"protocol": "matrix"
"host": "matrix.org"                                                           // Matrix homeserver
"id": "@marysmith:matrix.org"
"claim": "$bTa0eSTPecwj7obhfKQkfarQ5OyMDOX78AhBFaJdLpk"                        // event_ID of a post containing the user's DID
"proofs": ["ceramic://bafy123..."]

Suggested Usage

Accounts Index: The Social Account Links document stores a list of social accounts linked to a DID. However a DID may also wish to associate other types of accounts to their identity, such as crypto accounts, domain names, other DIDs, etc. The Accounts Index provides an index of accounts lists, and can contain a property called social which stores a link to a Social Account Links document. The recommended path from a DID to a Social Account Links document is: DID > Root Index > Accounts Index > Social Account Links.

Verification Services: For the account links in this document to be verified, they need to have a proof. Proofs are usually Verifiable Credential Doctypes issued by third-party verification services such as the one offered by 3Box.

Rationale

Decentralization & Trust: Linked account data needs to be globally-available, cross-platform, censorship-resistant, and live permissionlessly in the public domain (not on any single server). Additionally this information should be owned by a DID and will need to be updated from time to time. These requirements make Ceramic the most appropriate platform for publishing this content.

Implementation

Linked Accounts Array: Find the version of the Linked Accounts Array schema used for this document here. (TODO: Link after deployed)

Libraries: Not yet available.

Copyright

Copyright and related rights waived via CC0.

cip: 6
title: 3ID Doctype
author: Joel Thorstensson (@oed), Michael Sena (@michaelsena)
status: Draft
category: Standards
type: RFC
created: 2020-07-24
requires: Doctypes (CIP-5)

Simple Summary

This CIP describes the 3id doctype which is used to create DID documents. The DID standard provides a general format for verifiable decentralized digital identities. Given a specific DID string, a DID document which contains public keys, authentication authorization, etc. can be resolved.

Abstract

The 3id doctype allows DIDs to be created which are controlled by a management key and that have a separate signing key as well as an encryption key. Each update to a 3ID document is signed by the management key and encoded using dag-jose. A separate DID resolver can be implemented using ceramic to resolve a 3ID in the same way as any DID. This resolver converts the more compact content of the 3ID document into a standards compliant DID document.

Motivation

The original motivation for the design of the Ceramic protocol was to enable the most decentralized DID method possible. It was only later realized that Ceramic can be used for any type of document in a more abstract way. The 3id doctype therefore specifically defines a DID method based on Ceramic that fulfills the basic needs of a DID system. Since 3ID is native to Ceramic it works really nicely with the Ceramic protocol. A key feature of any DID method is the ability to revoke and rotate keys 3ID achieves this by relying on the security of the Ceramic conflict resolution system based on blockchain anchors.

Specification

Below the record formats and state transitions of the 3id doctype are specified. Together they should include all information needed to implement this doctype in Ceramic.

Record formats

The Genesis record are stored in IPLD using the dag-cbor codec. It has the following required properties:

• doctype - MUST equal 3id
• data - the initial JSON object of the document
• owners - a secp256k1 key encoded using multicodec

The JSON object of the document conform to the IPLD Schema defined below:

type GenesisContent struct {
  publicKey {String:String}
}

Where each entry in the publicKey map has a key which is the name of the public key, and a value which is a multicodec encoded public key. It is reccomended that the following keys are added:

• signing - a secp256k1 public key used for verifying signatures of the DID
• encryption - a x25519 public key used to encrypt messages to the DID

Signed records of a 3id document are encoded using dag-jose. Other than that they conform to the standard record format. The content of the data property should be a json-patch object which contains the difference from the previous document content state. The record should be signed by the managementKey (the key in the owner array) of the current document state.

State transitions

Below the state transition logic for the three different supported records is described.

Applying the Genesis Record

When the genesis record is applied a DocState object is created that looks like this:

{
  doctype: '3id',
  metadata: {
    owners: genesisRecord.owners
  },
  content: genesisRecord.data,
  signature: SignatureStatus.GENESIS,
  anchorStatus: AnchorStatus.NOT_REQUESTED,
  log: [new CID(genesisRecord)]
}

In addition to this, the following should be verified:

• owners is an multicodec encoded secp256k1 public key
• content should be a JSON object with the following requirements:
  • publicKey property contains a map with string keys and values which are DocIds
  • If present the index property should contain a docId as value

Applying a Signed Record

When a signed record is applied the DocState object should be modified in the following way:

state.next = {
  content: applyJSONPatch(state.content, signedRecord.data),
  metadata: {
    owners: signedRecord.owners
  }
}
state.signature = SignatureStatus.SIGNED
state.anchorStatus = AnchorStatus.NOT_REQUESTED
state.log.push(new CID(signedRecord))

Where applyJSONPatch is a function that applies a json-patch and returns a new json object. In addition the following should be validated:

• If owners is defined it should be secp256k1 public key that is different from state.metadata.owners.
• content should be a JSON object with the following requirements:
  • publicKey property contains a map with string keys and values which are DocIds
  • If present the index property should contain a docId as value
• The dag-jose signature should be valid and signed by the public key in the owners array in the metadata property (not the next.metadata property of the state)

Applying an Anchor Record

When an anchor record is applied the DocState object should be modified in the following way:

state.anchorStatus = AnchorStatus.ANCHORED
state.anchorProof = anchorRecord.proof
state.content = state.next.content
state.metadata = Object.assign(state.metadata, state.next.metadata)
delete state.next
state.log.push(new CID(anchorRecord))

No additional validation needs to happen at this point in the state transition function.

Rationale

The 3id specification provides a simple way to implement a DID method on top of Ceramic. The content of the document is different from a regular DID document and instead it's converted to a standards complient DID document using the 3id-did-resolver which makes the actual data stored and synced over the network much more minimal. The rules for what can go into the content of the document is left fairly minimal in order to allow for changes and iteration upon 3ID in the future.

Implementation

A reference implementation of the 3id doctype is provided in js-ceramic. (see the doctype-3id package).

Security Considerations

The 3ID doctype allows the owners array to change over time. This essentially allows users to do secure key rotation and revocation. Since the Ceramic protocol provides proof of publication of each document update and strict rules for how conflict resulution happens (earliest anchor wins), a user can be sure that their identity is safe even if old rotated keys gets compromised in the future.

Copyright

Copyright and related rights waived via CC0.

cip: 2
title: Ceramic Community Discord
author: Michael Sena (@michaelsena)
discussions-to:
status: Final
category: Meta
type:
created: 2020-06-14
requires:
replaces:

Simple Summary

This proposes Discord as a platform for fast-paced conversations about the Ceramic network.

Abstract

The Ceramic community needs a place where people can join to discuss things related to Ceramic.

Motivation

As an open source, decentralized protocol, it is important for Ceramic to have an open forum for community engagement. Discord provides a nice way to do that and is something many members of the web3 community are familiar with using. Unlike Slack, Discord has a nice identity model that doesn't require users creating new identities/logins for each community they join.

Implementation

Join Discord: Join the Ceramic Network Discord here.

Copyright

Copyright and related rights waived via CC0.

cip: 
title: Claim Doctype
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-05-22
requires:
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

This CIP specifies a Claim Doctype which can be used for creating W3C-compliant verifiable claims as Ceramic documents.

Abstract

Motivation

Claims should be issued to a DID.

Claims assert one or more statements about an individual or organization, not a specific account. For this reason, claims should be issued to a DID. By issuing claims to a DID, the claim instantly becomes reusable across all the accounts linked to the DID and everywhere the DID authenticates. This is especially important as users begin to use more wallet addresses to interact with applications. With this model, claims issuers get more usage out of their claims since they can be used in many more environments.

Claim state should be managed on a permissionless network.

In order for claims to be usable, their current state needs to be trusted by consumers. By using Ceramic documents to store the claims themselves or the hash of the current claim, issuers can easily perform version control of their claim in a simple, permissionless, and verifiable way.

*Claims can be made public.

If claims are stored on a server or offline on a device, availability is a huge variable. By storing some claims as permissionless documents on Ceramic, claims are always available and never offline.

Claims should be updatable.

Sometimes claims need to be updated after being issued. This is extremely difficult if claims are just vanilla signed data sitting offline or inside a user's data hub. However, by issuing claims as documents on Ceramic, they can be updated (version controlled) by simply updating the document. This is especially useful for claims that include non-static values or information such as credit scores, reputation, experience points, etc.

Claims should be easily revokable.

Sometimes claims need to be revoked after being issued. This is extremely difficult if claims are issued as vanilla signed data. The verifier of the claim would always need to validate the claim against some permissionless revocation registry to determine if the claim they received is still valid. However, claims issued as Ceramic documents simplify the revocation process entirely. The issuer only needs to update the document to make the claim invalid.

cip: 12
title: Root Index
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Draft
category: Standards
type: RFC
created: 2020-05-22
requires: Tile Doctype (CIP-8), DocId Map (CIP-10)

Simple Summary

Root Index is a document that acts as the root directory for a DID's resources.

Abstract

In an identity-centric model of development, users carry their identifier and resources with them across various contexts. Applications then use with these resources to provide service to the user. However in order to access resources, applications need an easy way to find them.

Currently, there is no standard and decentralized way of associating various resources, such as keys, accounts, profiles, social graphs, data, settings, and more to a DID. Because of this, there is no single location or interface for applications to query when discovering or interacting with a DID's resources, which restricts the adoption and potential use cases for decentralized identities.

The Root Index is a document that acts as an extensible top-level root directory for a DID's resources. It does not store the resources itself, but rather stores an index of subdirectories which in turn store pointers to resources. By standardizing how resources are associated to a DID, the Root Index is the foundational component needed to enable identity-centric resource discoverability.

Root Index is the top-level directory of the Identity Index (IDX) (CIP-11), and is used to store links to subdirectories such as the Profiles Index (CIP-13), Keychains Index (CIP-15), Accounts Index (CIP-14), Connections Index (CIP-18), Collections Index (CIP-16), Services Index (CIP-17), Settings Index (CIP-24), and more.

Motivation

Complete Decentralized Identities: Decentralized identifiers (DIDs) are the foundational requirement for interoperable, platform-agnostic identities. However, in practice "identity" is much more than just an identifier. Identity is the complete set of keys, accounts, data, resources, and capabilities that are associated with a DID. Since DIDs only provide an identifier, they are alone insufficient as identity. The Root Index provides a standardized core structure for associating resources to a DID that is infinitely extensible.

Identity-Centric Resource Indexing, Discoverability, and Routing: In a user-centric model of application development, when a user logs-in to a site, the site needs to discover and access the many resources associated with that user's DID to provide them service. However, these resources are likely scattered across the web on servers, distributed networks, etc. By supplying the logical, top-level routing information to all of these resources, the Root Index makes resources discoverable to any application.

DID-agnostic Standards: Given the number of DID providers only continues to increase, standardization around resource mappings is paramount; failing to do this will result in each DID method implementing their own system for resource routing which would limit the interoperability and utility of DIDs. The Root Index is compatible with any DID.

Specification

The Root Index specification includes a doctype, schema, table, and tag.

Doctype

Root Index is a Tile Doctype (CIP-8).

Schema

The Root Index utilizes the DocId Map (CIP-10) schema, which simply stores a list of strings which map to Ceramic DocIds. A reference to this schema should be included in your Root Index document when it is created.

Table

Root Index Table contains the standard set of properties that may be contained in any given Root Index. New properties can be added to the table by following the steps below. Additional properties not found in this table may be stored in any Root Index, however they may be less interoperable since others may not know what they represent. Here are some common examples of properties stored in Root Index:

• profiles: a link to the Profiles Index (CIP-13), a subdirectory for a DID's profiles
• keychains: a link to the Keychains Index (CIP-15), a subdirectory for a DID's keychains
• accounts: a link to the Accounts Index (CIP-14), a subdirectory for a DID's linked accounts (i.e. crypto & Oauth)
• connections: a link to the Connections Index (CIP-18), a subdirectory for a DID's social connections (i.e. follows)
• collections: a link to the Collections Index (CIP-16), a subdirectory for a DID's data collections (i.e. app data)
• services: a link to the Services Index (CIP-17), a subdirectory for a DID's services (i.e. notifications or backup)
• settings: a link to the Settings Index (CIP-24), a subdirectory for a DID's global settings (i.e. internationalization)

How to add a new property to the Root Index Table

1. Choose a unique, descriptive property name.
2. Add a description for your property.
3. Submit a PR to the CIP repository updating the Root Index Table with your property.
4. Mention the authors of this CIP in the comments of your PR.

Tags

When creating a Root Index document, add RootIndex to the tags field.

Example

An example Root Index document.

"doctype": "tile"
"schema": "<insert canonical schema for DocId Map>"
"tags": ["RootIndex", "DocIdMap"],
"content": {
  "profiles": "ceramic://bafyljsdf1",
  "accounts": "ceramic://bafysdfoijwe2",
  "keychains": "ceramic://bafysdfoijwe3",
  "services": "ceramic://bafysdfoijwe4",
  "collections": "ceramic://bafysdfoijwe5",
  "connections": "ceramic://bafysdfoijwe6",
  "settings": "ceramic://bafysdfoijwe7"
}

Suggested Usage

DIDs: Root Index can be used with any DID. A link to the DocId of the Root Index should be stored in the DID document, ideally under an index property to make it discoverable by simply resolving the DID document. The 3ID DID (CIP-6) native to Ceramic provides an optional index property and is fully compatible with Root Index.

Content: It is recommended that the Root Index be used as a root directory which only stores links to subdirectories which contain links to categorical subsets of resources. This keeps the Root Index minimal and provides a logical structure for information. The properties profiles, accounts, keychains, etc found in the Root Index Table above are examples of documents that act as subdirectories. For more information on how directories should be constructed for a DID, see the Identity Index (IDX) (CIP-11).

Rationale

Extensibility & Flexibility: It is impossible to predict all of the types of resources that need to be associated with any particular DID. Therefore the Root Index was designed to be infinitely extensible to support the indexing any kind of resource category or type.

Decentralization & Trust: Resource routing information is mission-critical data that needs to be globally-available, censorship-resistant, and live permissionlessly in the public domain (not on any single server). Additionally this information should be owned by a DID and will need to be updated from time to time. These requirements make Ceramic the most appropriate platform for publishing this content.

Implementation

DocId Map Schema: Find the DocID Map schema here.

Root index Table: Find the table containing standard Root Index properties here.

Libraries: Not yet available.

Copyright

Copyright and related rights waived via CC0.

cip: 
title: Data Interoperability Protocol (DIP)
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: RFC
created: 2020-05-22
requires:
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

Data Interoperability Protocol (DIP) is a standard framework for creating a DID-centric index of data collections that exist across all decentralized networks and centralized servers.

Abstract

DIP is an extension of the Identity Index Protocol (IIP) (CIP-11) that describes how to add data to a Collections Index (CIP-16) in a way that makes it universally discoverable and interoperable across applications and platforms.

Motivation

Data interoperability:

Unified, DID-centric data routing:

Cross-platform support:

Specification

cip: 
title: Sharded Pubsub
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: Networking
created: 2020-05-22
requires:
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

cip: 16
title: Collections Index
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Draft
category: Standards
type: RFC
created: 2020-05-23
requires: Tile Doctype (CIP-8), DocId to DocId Map (CIP-27)

Simple Summary

Collections Index is a document that stores a list of a DID's data collections.

Abstract

Collections Index provides a single place to associate various data collections to a DID. Individual collections can reference data that exists in a number of places from centralized servers (databases), to decentralized networks (i.e. Ceramic, Filecoin, Arweave, Textile, 3Box, Blockchains) and are usually used to represent user data created by an application or provided by some external data provider (i.e. reputation or scoring systems), but can be used for other purposes as well. By providing a unified location and standard interface for building these associations, the Collections Index can serve to provide a DID-centric data routing system that makes user data portable across platforms.

Collections Index is a subdirectory of the Identity Index (IDX) (CIP-11) and is often linked from the Root Index (CIP-12).

Motivation

Application developers will choose to store user data in a variety of places from decentralized networks to centrally hosted servers. However to realize the vision of a user-centric web where user data is portable across applications and interfaces, there needs to be a solution to cross-application data discoverability, routing, and interpretation. A third-party application needs to know which data is associated to the user, the shape or form of the data, and where to find it.

As a solution to this problem, the Collections Index aims to provide:

• A unified location for storing links to available data collections
• A standard interface for querying and routing to a DID's available data collections
• Optional user privacy and control by encrypting entries in this Index to obfuscate the relationship between a user and a given collection

Specification

The Collections Index specification consists of a doctype, schema, and tags.

Doctype

Collections Index is a Tile Doctype (CIP-8).

Schema

The Collections Index utilizes the DocId to DocId Map (CIP-27) schema, which simply stores a list of DocIds which map to other DocIds. A reference to this schema should be included in your Collections Index document when it is created.

For the Collections Index, the first DocId should be the DocId of a Collection Definition (CIP-28), which defines the collection as a set of data store types with specific schemas. (Since this document is usually owned by an application developer it also provides context as to the origin of the data.) The second DocId should be the DocId of a Collection Reference (CIP-29), which describes user-specific information about a given Collection Definition, such as unique store addresses, locations/hosts, etc.

Tags

When creating a Collections Index document, add CollectionsIndex to the tags field.

Example

Usage

Root Index: Collections Index provides a directory of collections, however collections are just one type of resource that can be associated with a DID. The Root Index (CIP-12) provides a top-level root directory for resources, and can contain a property called collections which stores a link to a Collections Index document. The recommended path for mapping from a DID to the Collections Index is: DID/Root Index/Collections Index.

Rationale

Extensibility & Flexibility: It is impossible to predict all of the types of collections that need to be associated with any particular DID. Therefore Collections Index was designed to be an infinitely extensible directory that can support any number of collections.

Decentralization & Trust: Collections directory information is data that needs to be globally-available, censorship-resistant, and live permissionlessly in the public domain (not on any single server). Additionally this information should be owned by a DID and will need to be updated from time to time. These requirements make Ceramic the most appropriate platform for publishing this content.

Implementation

DocId to DocId Map Schema: Find the DocId to DocId Map schema here.

Libraries: Not yet available.

Copyright

Copyright and related rights waived via CC0.

cip:
title: Ceramic Improvement Proposals (CIP)
author: Michael Sena (http://github.com/michaelsena)
discussions-to:
status: Last Call
category: Meta
type:
created: 2020-05-22
requires:
replaces:

Simple Summary

This proposal describes the process for Ceramic Improvement Proposals (CIPs).

Abstract

Ceramic Improvement Proposals (CIPs) are standards for improving the Ceramic platform, including core protocol specifications, client APIs, doctypes, and document standards. CIPs allow anyone to contribute to the development of the Ceramic Network and standards built on top of it. As a result, CIPs allow the Ceramic Network to thrive as an open source project and protocol.

Motivation

Here are some of the reasons why Ceramic needs a CIP process:

• To define an explicit governance process for Ceramic network upgrades
• To make it easy for community members to contribute to the development of the protocol
• To provide a way to discover implementation standards accepted by the community
• To provide a vehicle for community discussion around important topics
• To remove any individual or group of individuals as gatekeepers to the Ceramic Network

Specification

Process

1. Propose a new idea

Ideas are incomplete proposals meant to initiate community conversation.

Create a new issue in the CIP repository containing the idea for your your proposal, following the CIP template format. Be sure to add the Status: IDEA label to your issue.

2. Complete your draft

Drafts are complete proposals, but still undergoing rapid iteration and change.

Complete your proposal by filling out all appropriate fields in the CIP template. Update your proposal to Status: DRAFT in the issue header and Github label. Gather community feedback and make improvements as required.

3. Enter last call for community feedback

Last Calls are stable proposals ready for final review by the community.

Once you feel that your proposal is stable and ready for final review by the community, update your proposal to Status: LAST CALL in the issue header and Github label. In order to proceed beyond Last Call, your issue must remain in Last Call for at least 2 weeks and any technical changes that are requested must be addressed by the author.

4. Submit a Pull Request

Pull Requests are CIPs ready for consideration by editors and/or core devs.

When your proposal exits Last Call, you should submit a Pull Request to the CIP repository. To do this, fork the CIP repository by clicking "Fork" in the top right. Add your CIP to your fork of the repository. Update your proposal to Status: PENDING in the issue header and Github label (on both your previous open issue and new PR). Then, submit a Pull Request to the CIP repository.

Upon submission an editor will manually review the first PR for a new CIP, assign it a canonical number (i.e. CIP-1), and merge it into the CIP repo. They will then reach out to discuss next steps to achieve finalization. These steps will depend on whether or not your CIP is of type Core.

When submitting your Pull Request:

• Images: If your CIP requires images, the image files should be included in a subdirectory of your CIP folder as follows: CIP-N/assets (where N is to be replaced with the CIP number). When linking to an image in the CIP, use relative links such as ./assets/image.png.

• Tables: If your CIP requires csv tables, the table csv files should be included in a subdirectory of your CIP folder as follows: CIP-N/tables (where N is to be replaced with the CIP number). When linking to a table in the CIP, use relative links such as ./tables/table.csv.

5. Get your CIP finalized

Finalized CIPs are CIPs that are have been approved.

5a. If your CIP is a Core CIP

An editor will reach out to provide the dates of the upcoming Ceramic Core Devs calls. Once you select one, your issue will be added to the agenda for that call where it will be discussed for inclusion in a future network upgrade.

If implementers agree to include your CIP in a future network upgrade, CIP editors will update your CIP to Status: ACCEPTED. Once your proposal has been released in a network upgrade, CIP editors will update your CIP to Status: FINAL.

If implementers decide not to include your CIP in a future network upgrade for whatever reason, you are always able to propose it again at a later time. It will remain as Status: PENDING in the CIP repo.

5b. If your CIP is a non-Core CIP

An editor will ask if anyone objects to it being finalized. If the editor decides there is no rough consensus - for instance, because contributors point out significant issues with the CIP - they may close the PR and request that you fix the issues in the draft before trying again. If the editor finds there is rough consensus, they will merge the PR and update it to Status: FINAL.

CIP Terms

Categories

• Standards: an CIP that affects the protocol or is an implementation standard.
• Meta: an CIP that affects the governance process for CIPs.
• Informational: an CIP that is merely for informational purposes but requires no action by the community, and will not be merged as a CIP.

Types

Only applicable to CIPs of type Standards.

• Core: an CIP that affects the core protocol.
• Networking: an CIP thst affects the networking layer (i.e. libp2p or syncing).
• Interface: an CIP that affects the Ceramic API or provider interface.
• RFC: an CIP that proposes an implementation standard (i.e. doctypes, document configurations, or document schemas).

Statuses

• Idea: an CIP issue that is incomplete.
• Draft: an CIP issue that is undergoing rapid iteration and changes.
• Last Call: an CIP issue that is stable and ready for final review by the community.
• Pending: an CIP that has been merged but not finalized.
• Accepted (Core): an CIP of type Core that has been accepted by the core devs to be included in a future network upgrade.
• Final (Core): an CIP of type Core that has already been released in a network upgrade.
• Final (non-Core): a non-core CIP that has met all criteria and is finished.

Rationale

It is prudent to look at other successful examples of open source software governance. CIPs are inspired by the previous work of Ethereum (EIPs), Bitcoin (BIPs), Python (PIPs), and others. CIP is slightly different in implementation than those examples, but shares many similarities. In some cases, CIP even borrows certain language from those examples.

Implementation

• Official Process: This CIP and the README of the CIP repository.
• Issue Template: Create a new CIP issue here.

Copyright

Copyright and related rights waived via CC0.

This has been deprecated in favor of the more general Access Control Document.

Discussion for CIP-19: Basic Profile Definition.
Up to date spec in PR #66

cip: 27
title: DocId to DocID Map
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
status: Idea
category: Standards
type: RFC
created: 21-07-2020
requires: Tile Doctype (CIP-8)

Simple Summary

DocId to DocId Map defines a schema that stores a list of mappings from DocId to DocId.

Abstract

For many use cases of Ceramic it is desirable to create a document that simply stores a list of mappings from a DocId to another DocId.

Motivation

Such a standard would be helpful in defining a basic schema that many in the Ceramic ecosystem can use when creating documents.

Specification

The DocId to DocId Map specification consists of a doctype, a schema, and a tag.

Doctype

The DocId to DocId Map is a Tile Doctype (CIP-8).

Schema

The DocId to DocId Map schema defines a document which maintains a list of DocIds that map to other DocIds. If a document uses this schema, these rules will be enforced by the Ceramic protocol.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "title": "DocIdDocIdMap",
  "propertyNames": {
    "pattern": "^ceramic://.+"
  },
  "additionalProperties": {
    "$ref": "#/definitions/CeramicDocId"
  },
  "definitions": {
    "CeramicDocId": {
      "type": "string",
      "pattern": "^ceramic://.+(\\?version=.+)?"
    }
  }
}

Tags

When creating a document that conforms to the DocId to DocId Map schema, add DocIdDocIdMap to the tags field.

Rationale

This proposal is fairly straightforward and no other design considerations were made.

Implementation

DocId to DocId Map Schema: This version of the DocId to DocId Map schema can be found at ceramic://bafy.../?version (will update after it is deployed)

Usage

When creating a new document that conforms to the DocId to DocId Map schema, you should include the schema version included above in the schema property and the DocIdDocIdMap tag in the tags property.

Copyright

Copyright and related rights waived via CC0.

Discussion for CIP-23.

PR: #70

Discussion for CIP-7.

cip: 
title: Support ethr-did resolver
author: Michael Sena (@michaelsena), Joel Thorstensson (@oed)
discussions-to:
status: Idea
category: Standards
type: Core
created: 2020-05-22
requires:
replaces: 

🚨 This is a placeholder for an idea, and we will work to draft the CIP at a later time. Feel free to leave comments and ideas on this issue.

Simple Summary

This CIP proposes adding support for the ethr-did reslover to Ceramic. This would allow Ceramic documents to be created and managed with DIDs that conform to ethr-did method.

Abstract

Motivation

Multi-DID support: As Ceramic aims to be a DID-agnostic protocol, it should have the ability to resolve more DID signatures than just 3IDs. Ethr DID is a standard that some in the Ethereum community have used and it would be good to allow those DIDs to create and interact with documents in Ceramic.

Specification

Discussion for CIP-5.