Rm ceramic until after launch, or on second pass
This commit is contained in:
parent
280b77c642
commit
60f2fc6e22
|
@ -1,116 +0,0 @@
|
||||||
## Overview
|
|
||||||
|
|
||||||
Ceramic is a permissionless protocol for creating and accessing mutable, tamper-proof documents. This provides a verifiable, censorship-resistant source of truth for important information that is public and interoperable, unlocking interoperability between all platforms, services and technologies.
|
|
||||||
|
|
||||||
Ceramic is designed first and foremost to provide an interoperable decentralized identity infrastructure that works across networks, keys, use cases, and technologies. Linked Ceramic documents are perfect for storing decentralized identifiers and their associated metadata, account links, policies (e.g., privacy & services), profile information and links, databases, data schemas, and routing to other off-network resources (whether on a blockchain, server or elsewhere).
|
|
||||||
|
|
||||||
This creates a truly cross-platform decentralized identity and user-centric routing system that can bridge all silos together and let developers across networks and stacks build in a composable and efficient manner. Ceramic complements data protocols like GUN, Hypercore and IPFS, messaging protocols like Signal and Iris, and other distributed and cryptography based technologies. The core primitives of linked verifiable documents can be used for a wide range of applications by app and service developers (public service terms, API endpoints) and technologies (access logs) beyond identity.
|
|
||||||
|
|
||||||
### Data Structure / Layer
|
|
||||||
|
|
||||||
Ceramic Documents are encoded in [IPLD](https://ipld.io/) and form a Merkle DAG.
|
|
||||||
|
|
||||||
Each Ceramic document is an append-only log signed by DIDs. This forms individual doc-chains that can store any kind of info. Each entry in this log is called a record. When a document is changed an update record is created which contains the patch. Each update record is followed by an anchor record which contains a proof that the new update has been anchored on-chain.
|
|
||||||
|
|
||||||
Docs have permalinks and versioning built in. The CID (content identifier (hash)) of the anchor record can be used to refer to this specific version of the document.
|
|
||||||
|
|
||||||
Docs are stored on Ceramic nodes, which can use any persistence layer (distributed file storage, blockchain, server, etc.) they choose as long as they return accurate and latest state of the document.
|
|
||||||
|
|
||||||
Updates can also be anchored on a blockchain for additional verifiability, discovery and strict ordering. The protocol is agnostic as to which blockchain is used for anchoring and a document could potentially be anchored in multiple chains. This gives flexibility on cost/security tradeoffs needed for different use cases.
|
|
||||||
|
|
||||||
Ceramic documents can (and are designed to) point to other databases and resources off network, and make them easily discoverable and accessible by publishing key metadata on-network.
|
|
||||||
|
|
||||||
Immediately supported are OrbitDB (KV stores, feed stores) and Textile (threadsDB), both built atop IPFS. Over time other DBs will be added, including server-based.
|
|
||||||
|
|
||||||
### Network Structure
|
|
||||||
|
|
||||||
Public, permissionless network of nodes that gossip via Libp2p
|
|
||||||
|
|
||||||
Local-first, with immediate writes to in-client nodes then syncing out to the network
|
|
||||||
|
|
||||||
Nodes can choose what documents to store and follow. Apps and users can choose what nodes to request documents from.
|
|
||||||
|
|
||||||
Document updates are periodically anchored on a blockchain using an anchoring service; each app or node can configure their preferred anchoring service and options.
|
|
||||||
|
|
||||||
### Identity
|
|
||||||
|
|
||||||
Any DID can be used as an identity in Ceramic; Ceramic has a native "3ID" implementation
|
|
||||||
|
|
||||||
The first and primary use case for Ceramic is a robust, flexible and interoperable identity standard built around DIDs that other networks, data technologies, and infrastructure can leverage in order to provide interoperability between them and across applications leveraging them.
|
|
||||||
|
|
||||||
The full and [current identity standard can be found here](https://github.com/ceramicnetwork/CIP/issues/3).
|
|
||||||
|
|
||||||
Key capabilities of the identity standard are:
|
|
||||||
|
|
||||||
- Any DID can be used, and DIDs have an account document pointing to other resources. These include..
|
|
||||||
- A keychain of authentication methods, letting infinitely many keys (blockchain, DB, other) link to the same DID, providing persistent identity across networks and technologies.
|
|
||||||
- For example, the same identity can be used to manage DB access control and to authenticate into ethereum apps
|
|
||||||
- This means key management can be done in any / many ways depending on app, network, user preferences
|
|
||||||
- Shared account metadata that can be leveraged across applications, networks and technologies
|
|
||||||
- Account links to prove ownership of on-chain or other cryptographic accounts
|
|
||||||
- Routing to external resources, including databases and preferred services (e.g., so not every app or network needs a separate notification service and settings)
|
|
||||||
- Additional data managed off the identity standard can include claims (reputational, KYC), access control policies, connections (shared social graph), and more
|
|
||||||
|
|
||||||
All of this is built on a flexible and modular graph of Ceramic documents, allowing for easy updating, versioning and extensibility.
|
|
||||||
|
|
||||||
Some documents are public and some are encrypted, depending on the privacy preferences of the user and the use case. All documents can be deleted completely by the user (controller) at any time.
|
|
||||||
|
|
||||||
The identity standard also interoperates with other standards like the "interoperable data standard," which lets database and application developers publish schema and endpoints of user data, thus making data practically discoverable and interoperable across apps and networks even while being fully private and secure.
|
|
||||||
|
|
||||||
In addition to using this standard to manage access control to off-chain resources (e.g., databases), DIDs can also delegate account management to other DIDs. This enables flexible models for account recovery, shared accounts, use for organizations or DAOs or devices, or other entities that need identity.
|
|
||||||
|
|
||||||
### Discovery
|
|
||||||
|
|
||||||
A core feature of Ceramic is identity-centric routing. Apps, services and users can trace the DID and its associated document graph to quickly arrive at the relevant information. This not only makes discovery incredibly efficient for Ceramic, but makes it a discovery and scalability tool for other networks.
|
|
||||||
|
|
||||||
Ceramic can also be used to publish metadata about off-network resources (e.g., schema and endpoints for databases, service offerings and terms for APIs) thus making them highly discoverable. Because service agreements (e.g., between apps and services) can be encoded in a Ceramic document, there is a native signaling and reputation that helps useful resources get discovered by others on the network.
|
|
||||||
|
|
||||||
### Curation / moderation /Filtering
|
|
||||||
|
|
||||||
Blocklists can be implemented via clientside filtering in ipfs
|
|
||||||
|
|
||||||
Future implementation could enable a native blocklist for certain docIds in documents. This would allow shared and followed blocklists
|
|
||||||
|
|
||||||
### Scalability
|
|
||||||
|
|
||||||
Verifying a particular document only requires a user to sync the specific data of the given document. A node in the Ceramic network can thus choose to only *pin* the documents it cares about. This means that there is no global ledger of documents.
|
|
||||||
|
|
||||||
Ceramic documents must conform to flexible but specified state transition logic defined by "doctypes". This allows Ceramic nodes to verify the state of a given document in a decentralized and efficient way.
|
|
||||||
|
|
||||||
Document updates are written local-first and then synced to the network.
|
|
||||||
|
|
||||||
Updates anchored on any blockchain are done so in batches in a merkle tree encoded in IPLD, and can be done by multiple services to multiple blockchains, so is not a bottleneck even at massive scale.
|
|
||||||
|
|
||||||
### Governance
|
|
||||||
|
|
||||||
Ceramic protocol is open source.
|
|
||||||
|
|
||||||
Ceramic Network will be public and permissionless for all types of participation. Anyone can run a node (users, apps, service providers) and pin documents. Any DID can create documents and sign updates. Any app or service can publish ceramic documents.
|
|
||||||
|
|
||||||
A core piece of the practical usage of Ceramic is through core standards. Ongoing governance of Ceramic is managed by the [CIP](https://github.com/ceramicnetwork/CIP) process. This is relatively informal currently and will get more formal as the network grows and more governance moves from core contributors to the broader community.
|
|
||||||
|
|
||||||
### Monetization & Business models
|
|
||||||
|
|
||||||
There may be a need for an incentive to ensure ceramic nodes are returning the latest accurate state of ceramic documents. If so, this is a likely candidate for a token that helps make the network more efficient while rewarding both core contributors and network participants.
|
|
||||||
|
|
||||||
Teams building on top of Ceramic, including 3Box Inc, will monetize by charging for services on Ceramic including data hosting, notifications, verification services, and other services that build on Ceramic's core functionality.
|
|
||||||
|
|
||||||
### Interoperability
|
|
||||||
|
|
||||||
Ceramic is designed to aid interoperability of all decentralized protocols. Because any key can be linked to a DID and any DID can be used to create documents and documents can contain any metadata or content, is a perfect way for individual networks or implementations to make themselves discoverable and interoperable with other web3 technologies.
|
|
||||||
|
|
||||||
Ceramic is built on IPFS/IPLD, working closely with OrbitDB and Textile.
|
|
||||||
|
|
||||||
By Fall 2020, multiple blockchain keys including filecoin, Flow, Arweave, Polkadot and others will be supported. Many wallet providers will be leveraging Ceramic. It is straightforward to add support for other distributed DBs and messaging protocols. And many core services like The Graph (indexing) will be operating on Ceramic. As will 700+ decentralized applications currently using 3Box.
|
|
||||||
|
|
||||||
### Resources
|
|
||||||
|
|
||||||
Slightly outdated [overview](https://github.com/ceramicnetwork/ceramic/blob/master/OVERVIEW.md) and [specs](https://github.com/ceramicnetwork/specs).
|
|
||||||
|
|
||||||
Current high level [development roadmap](https://github.com/ceramicnetwork/ceramic/issues/19).
|
|
||||||
|
|
||||||
[Discord community](https://discord.gg/DM4BS98)
|
|
||||||
|
|
||||||
### Stats & implementations
|
|
||||||
|
|
||||||
[3Box.io](http://3box.io) is an initial implementation with 700+ applications built on top and >20,000 user identities and data stores created.
|
|
Loading…
Reference in New Issue