From fac524edda0f04618e330d0f80ee4a94c5d5a5a9 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:44:51 +0200 Subject: [PATCH 01/13] fix typo --- docs/learn/roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/learn/roadmap.md b/docs/learn/roadmap.md index 5a0e219b1..64f36c204 100644 --- a/docs/learn/roadmap.md +++ b/docs/learn/roadmap.md @@ -5,7 +5,7 @@ to both ComposeDB and the underlying Ceramic protocol. Concurrently, we seek to community in shaping Ceramic's future. We value your active participation in helping us prioritize the features and improvements that matter most to our developer base. -**All curent and future projects are outlined in the [Ceramic roadmap](https://github.com/orgs/ceramicstudio/projects/2).** +**All current and future projects are outlined in the [Ceramic roadmap](https://github.com/orgs/ceramicstudio/projects/2).** We welcome your feedback and insights on our roadmap priorities. You can show your support or express your concerns about projects on the roadmap by upvoting or downvoting them. Additionally, we encourage you to leave more detailed From 270ca39bf2fb323bbea690c0f8e950ec841dc888 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:46:44 +0200 Subject: [PATCH 02/13] fix typo --- docs/learn/highlighted-projects.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/learn/highlighted-projects.md b/docs/learn/highlighted-projects.md index d564a1665..20b1d4c02 100644 --- a/docs/learn/highlighted-projects.md +++ b/docs/learn/highlighted-projects.md @@ -33,7 +33,7 @@ Decentralized universal profiles available for use throughout the web3 metaverse |[Titter](https://twitter.com/dabit3/status/1515698468949573634)|Titter is a prototype of a web3-native social application, using Ceramic for editable, self-sovereign user profiles.|[Demo](https://twitter.com/dabit3/status/1515698468949573634)|[Github](https://github.com/dabit3/titter)| ### Reputation -This includes any publicly veriable attestations for skills, credentials, and contribution scores. +This includes any publicly verifiable attestations for skills, credentials, and contribution scores. |Project |Description |Demo |Code Repo| |-|----|-----|--| From 1a39e181bb5c741e006ff9680a1b8182f706e749 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:47:43 +0200 Subject: [PATCH 03/13] fix typo --- docs/learn/glossary.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/learn/glossary.md b/docs/learn/glossary.md index 598e64209..893531019 100644 --- a/docs/learn/glossary.md +++ b/docs/learn/glossary.md @@ -14,7 +14,7 @@ A StreamID is an immutable identifier for a [stream](#stream). StreamIDs enable ### StreamTypes -StreamTypes are functions used for processing updates to [streams](#streams). StreamTypes handle everything from defining the data structure of the stream, to what can be stored in its [commits](#commits), its state transitition function, [authentication](#authentication) requirements, and [conflict resolution strategy](#conflict-resolution-strategy). Every stream must specify a StreamType; and StreamTypes run on Ceramic [nodes](#nodes). Ceramic comes [pre-installed with various StreamTypes](../docs/advanced/standards/stream-programs/index.md), or you can code your own. +StreamTypes are functions used for processing updates to [streams](#streams). StreamTypes handle everything from defining the data structure of the stream, to what can be stored in its [commits](#commits), its state transition function, [authentication](#authentication) requirements, and [conflict resolution strategy](#conflict-resolution-strategy). Every stream must specify a StreamType; and StreamTypes run on Ceramic [nodes](#nodes). Ceramic comes [pre-installed with various StreamTypes](../docs/advanced/standards/stream-programs/index.md), or you can code your own. ### Commits From 94124c6c20489dcea19378cc5bd75cb73468f8ad Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:48:24 +0200 Subject: [PATCH 04/13] fix typo --- docs/learn/blog.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/learn/blog.md b/docs/learn/blog.md index fe1e30e78..711f3daa1 100644 --- a/docs/learn/blog.md +++ b/docs/learn/blog.md @@ -16,7 +16,7 @@ The [**Ceramic Blog**](https://blog.ceramic.network){:target="\_blank"} contains ## Featured videos -[**Learn how to manage user data in a Web3 app with IDX**](https://blog.ceramic.network/learn-how-to-manage-user-data-in-a-web3-app-with-idx/){:target="\_blank"}: Learn how to manage user data for your Web3 application with IDX. This talk is a workshop from tthe ETHDenver 2021 hackathon. +[**Learn how to manage user data in a Web3 app with IDX**](https://blog.ceramic.network/learn-how-to-manage-user-data-in-a-web3-app-with-idx/){:target="\_blank"}: Learn how to manage user data for your Web3 application with IDX. This talk is a workshop from the ETHDenver 2021 hackathon. [**Standards for encrypted and mutable data on IPFS**](https://blog.ceramic.network/standards-for-encrypted-and-mutable-data-on-ipfs/){:target="\_blank"}: Joel talks about new standards for signed, encrypted, mutable data on IPFS. This is a talk from the ETHDenver 2021 hackathon. From da7fc538a42caf4eb346cc6f40db585cb94325bf Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:49:08 +0200 Subject: [PATCH 05/13] fix typo --- docs/learn/network/clients.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/learn/network/clients.md b/docs/learn/network/clients.md index c8d8fe3f7..b5668fe7a 100644 --- a/docs/learn/network/clients.md +++ b/docs/learn/network/clients.md @@ -69,7 +69,7 @@ Should this be its own category, or should this live elsewhere? The primary responsibility of an anchor service is to generate anchor records by committing signed records into a blockchain. All of the responsibilities below are in service of this primary responsibility. #### Merkle tree construction -Constructs a merkle tree of all signed records that eill be simultaneously committed to a blockchain in a single hash, called a merkle root. +Constructs a merkle tree of all signed records that will be simultaneously committed to a blockchain in a single hash, called a merkle root. #### Anchor metadata Bloom filter, helps with indexing services. From ce8863d684e559cd23c1ec01788a332e45a58167 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:50:33 +0200 Subject: [PATCH 06/13] fix typos --- docs/learn/advanced/consensus.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/learn/advanced/consensus.md b/docs/learn/advanced/consensus.md index 350de1944..c3c18e877 100644 --- a/docs/learn/advanced/consensus.md +++ b/docs/learn/advanced/consensus.md @@ -26,11 +26,11 @@ Whatever the reason for the diverging logs for a single Stream, it is important #### Earliest Anchor Wins -Updates to Ceramic Streams are periodically [anchored](../glossary.md#anchor-commit) onto a blockchain (currently Ethereum). This immutable proof-of-publication is used to get a trustless timestamp for when the update occurred. This allows us to safely compare the timestamps associated with different branches of a Stream's log to determine which update happened first. When there are conflicting histories for a Stream log and one branch was anchored earlier than the other, the branch that was anchored earlier wins. If one branch was anchored and the other not, then the branch that was anchored is prefered. +Updates to Ceramic Streams are periodically [anchored](../glossary.md#anchor-commit) onto a blockchain (currently Ethereum). This immutable proof-of-publication is used to get a trustless timestamp for when the update occurred. This allows us to safely compare the timestamps associated with different branches of a Stream's log to determine which update happened first. When there are conflicting histories for a Stream log and one branch was anchored earlier than the other, the branch that was anchored earlier wins. If one branch was anchored and the other not, then the branch that was anchored is preferred. #### Longest update chain -The Earliest Anchor Wins rule can solve many problems related to coming to consensus on a Stream's state, but still has issues if multiple updates are created quickly. Since anchors only happen periodically (depends on the anchor service being used, but currently twice a day for the anchor service that 3Box Labs operates for Ceramic mainnet), multiple updates can be created and published before any of them get anchored. In that case, we still need to come to consensus on the current state. When there are conflicting logs for a stream neither of which have been anchored, we prefer whichever log is longer. This ensures that the most active history with the most updates is preserved. If there are conflicting unanchored branches that have the same length, then the system picks the winning log arbtrarily, but deterministically, to ensure that all nodes come to agreement on the same log, even if there is no good information available to use to decide which to prefer. This can result writes being lost in certain rare instances where there are conflicting updates published within a few seconds of each other. +The Earliest Anchor Wins rule can solve many problems related to coming to consensus on a Stream's state, but still has issues if multiple updates are created quickly. Since anchors only happen periodically (depends on the anchor service being used, but currently twice a day for the anchor service that 3Box Labs operates for Ceramic mainnet), multiple updates can be created and published before any of them get anchored. In that case, we still need to come to consensus on the current state. When there are conflicting logs for a stream neither of which have been anchored, we prefer whichever log is longer. This ensures that the most active history with the most updates is preserved. If there are conflicting unanchored branches that have the same length, then the system picks the winning log arbitrarily, but deterministically, to ensure that all nodes come to agreement on the same log, even if there is no good information available to use to decide which to prefer. This can result in writes being lost in certain rare instances where there are conflicting updates published within a few seconds of each other. #### Simultaneous updates From 5cba1a7020118f5a8ca317e10eecd46ceb0c6458 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:51:17 +0200 Subject: [PATCH 07/13] fix typo --- docs/learn/advanced/data-availability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/learn/advanced/data-availability.md b/docs/learn/advanced/data-availability.md index 83a5bb91b..9b9da976b 100644 --- a/docs/learn/advanced/data-availability.md +++ b/docs/learn/advanced/data-availability.md @@ -20,7 +20,7 @@ If the node happens to shut down or restart, the cache will be cleared. Without Pinning provides a more long-lived mechanism of data persistence for commits. Pinning is a process for instructing a Ceramic node to explicitly host (i.e. "pin") the commits for a specific stream. Since commits are stored in IPLD, Ceramic nodes already contain a bundled [IPFS](../glossary.md#ipfs) node which is where this pinning occurs. IPFS nodes can pin all commits for any stream which is accessible over the Ceramic network to which it is connected. Ceramic pinning can also work using an external IPFS node instead of the bundled internal version. -If developers want the easiest way to make their streams persistent beyond a single session and more resilient against data loss, then pinning is the right option. Ceramic nodes can pin an unlimited number of streams. However, note that if only one IPFS node is pinning a given stream and it disappears forever or gets corrupted, then that stream will be lost. Also, if only one node is pinning a stream (and no other Ceramic nodes have it in cache) and that node goes offline, then that stream will be unavailable to others. Therefore, for improved resilience and data availability it is best to have multiple IPFS nodes running in different envitonments pinning the same streams. +If developers want the easiest way to make their streams persistent beyond a single session and more resilient against data loss, then pinning is the right option. Ceramic nodes can pin an unlimited number of streams. However, note that if only one IPFS node is pinning a given stream and it disappears forever or gets corrupted, then that stream will be lost. Also, if only one node is pinning a stream (and no other Ceramic nodes have it in cache) and that node goes offline, then that stream will be unavailable to others. Therefore, for improved resilience and data availability it is best to have multiple IPFS nodes running in different environments pinning the same streams. > See the [Pinning](../../build/javascript/pinning.md) guide for instructions on how to pin streams on a Ceramic node. From 5a6d4b60ca9ab0b2b5ef23165678fe85aa0b234f Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:53:03 +0200 Subject: [PATCH 08/13] fix typos --- docs/learn/advanced/overview.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/learn/advanced/overview.md b/docs/learn/advanced/overview.md index 49d6b286a..895293acc 100644 --- a/docs/learn/advanced/overview.md +++ b/docs/learn/advanced/overview.md @@ -53,7 +53,7 @@ DIDs provide a way to go from a globally-unique, platform-agnostic string identi - **[PKH DID Method](../../docs/advanced/standards/accounts/pkh-did.md)**: A DID method that natively supports blockchain accounts. DID documents are statically generated from a blockchain account, allowing blockchain accounts to sign, authorize and authenticate in DID based environments. - **[3ID DID Method](../../docs/advanced/standards/accounts/3id-did.md)**: A DID method that uses Ceramic's Tile Document StreamType to represent a mutable DID document. 3IDs are typically used for end-user accounts. When 3IDs are used in conjunction with [the Identity Index protocol](../../docs/advanced/standards/application-protocols/identity-index.md) and the [3ID Keychain](https://github.com/ceramicnetwork/CIP/blob/main/CIPs/CIP-20/CIP-20.md){:target="\_blank"} (as is implemented in [3ID Connect](../../docs/advanced/standards/accounts/3id-did.md#3id-connect)), a 3ID can easily be controlled with any number of blockchain accounts from any L1 or L2 network. This provides a way to unify a user's identity across all other platforms. - **[Key DID Method](../../docs/advanced/standards/accounts/key-did.md)**: A DID method statically generated from any Ed25519 key pair. Key DIDs are typically used for developer accounts. Key DID is lightweight, but the drawback is that its DID document is immutable and has no ability to rotate keys if it is compromised. -- **[NFT DID Method](../../docs/advanced/standards/accounts/nft-did.md) (coming soon)**: A DID method for any NFT on any blockchain. The DID document is statically generated from on-chain data. The DID associated to the blockchain account of the asset's current owner (using CAIP-10 Links) is the only entity authorized to act on behalf of the NFT DID, authenticate in DID-based systems, and make updates to streams or other data owned by the NFT DID. When owenership of the NFT changes, so does the controller permissions. +- **[NFT DID Method](../../docs/advanced/standards/accounts/nft-did.md) (coming soon)**: A DID method for any NFT on any blockchain. The DID document is statically generated from on-chain data. The DID associated to the blockchain account of the asset's current owner (using CAIP-10 Links) is the only entity authorized to act on behalf of the NFT DID, authenticate in DID-based systems, and make updates to streams or other data owned by the NFT DID. When ownership of the NFT changes, so does the controller permissions. - **[Safe DID Method](../../docs/advanced/standards/accounts/safe-did.md) (coming soon)**: A DID method for a Gnosis Safe smart contract on any blockchain. Typically used for organizations, DAOs, and other multi-sig entities. ## **Ceramic Network** @@ -108,9 +108,9 @@ Getting started with Ceramic is simple. Visit the [**Quick Start**](../../build/ ### Tools and services -In addition to various standards referenced throughout this document, the Ceramic community has already begun delevoping many different open source protocols, tools, and services that simplify the experience of developing on Ceramic. Here are a few notable examples: +In addition to various standards referenced throughout this document, the Ceramic community has already begun developing many different open source protocols, tools, and services that simplify the experience of developing on Ceramic. Here are a few notable examples: -- [**3ID Connect:**](../../docs/advanced/standards/accounts/3id-did.md#3id-connect) A authentication SDK for browser-based applications that allows your users to transact with Ceramic using their blockchain wallet. +- [**3ID Connect:**](../../docs/advanced/standards/accounts/3id-did.md#3id-connect) An authentication SDK for browser-based applications that allows your users to transact with Ceramic using their blockchain wallet. - [**Identity Index (IDX):**](../../docs/advanced/standards/application-protocols/identity-index.md) A protocol for decentralized identity that allows a DID to aggregate an index of all their data from across all apps in one place. IDX enables user-centric data storage, discovery, and interoperability. It is effectively a decentralized, cross-platform user table. IDX can reference all data source types, including Ceramic streams and other peer-to-peer databases and files. - [**IdentityLink:**](../../tools/identitylink/overview.md) A service that issues verifiable claims which prove a DID owns various other Web2 social accounts such as Twitter, Github, Discord, Discourse, Telegram, Instagram, etc. Once issued, claims are stored in the DID's Identity Index. - [**Documint:**](http://documint.net/){:target="\_blank"} A browser-based IDE for creating and editing streams. From ea10e35b141a638dedf661f9fea24731205eeb64 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:54:45 +0200 Subject: [PATCH 09/13] fix typo --- docs/pages/3box-migration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/3box-migration.md b/docs/pages/3box-migration.md index 8b5d34027..97dfade59 100644 --- a/docs/pages/3box-migration.md +++ b/docs/pages/3box-migration.md @@ -8,7 +8,7 @@ Any additional data in 3Box may or may not be migrated by the applications thems ## **Migration Difficulties** -Most users will be able to migrate without difficulty, but there is a number of known instances where we can not easily migrate your 3ID. In theses cases we will create a new 3ID for you and partially migrate any data that we can. You will be able to re-add any profile data and social links that fail to migrate in the future. +Most users will be able to migrate without difficulty, but there is a number of known instances where we can not easily migrate your 3ID. In these cases we will create a new 3ID for you and partially migrate any data that we can. You will be able to re-add any profile data and social links that fail to migrate in the future. **Very Early 3Box Users** From 8a178550572a1ffaa7f341c6d53d54f7bbcf7f62 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:55:53 +0200 Subject: [PATCH 10/13] fix typo --- docs/protocol/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/protocol/nodes.md b/docs/protocol/nodes.md index de9ade07d..6428b87a1 100644 --- a/docs/protocol/nodes.md +++ b/docs/protocol/nodes.md @@ -16,7 +16,7 @@ The following services are typically provided to a Ceramic node by a connected I | --- | --- | | Gossipsub | Several layers of the libp2p stack are used including GossipSub to query streams and broadcast stream updates in the network. | | Kademlia DHT | A distributed hash table for content and peer lookup and discovery. The same DHT table is used as the primary IPFS network. | -| Bitswap | Exchange and sync blocks with peers. Allows an event stream to be sycned from one node to another. | +| Bitswap | Exchange and sync blocks with peers. Allows an event stream to be synced from one node to another. | ### **Ceramic Services** From 89cf0b04e60d5f01d404fb9b229cd41243cafda1 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:56:48 +0200 Subject: [PATCH 11/13] fix typo --- docs/protocol/accounts/authorizations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/protocol/accounts/authorizations.md b/docs/protocol/accounts/authorizations.md index 51f384273..546dbbcbd 100644 --- a/docs/protocol/accounts/authorizations.md +++ b/docs/protocol/accounts/authorizations.md @@ -22,7 +22,7 @@ For example, to authorize an account to write to only two specific streams, you ### **Models** -The mostly commonly used pattern is to specify authorizations by model streamIds. `model` is a property that can be defined in a streams init event. When specified and used with CACAO it allows a DID and key the ability to write to all streams with this specific model value for that user. +The most commonly used pattern is to specify authorizations by model streamIds. `model` is a property that can be defined in a streams init event. When specified and used with CACAO it allows a DID and key the ability to write to all streams with this specific model value for that user. !!! note Ceramic will likely support other keys and values in streams beyond `model` for authorizations in the future. From d1a51664cb041b0e09ef612627097c9034b4fc31 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 22 Sep 2023 10:58:01 +0200 Subject: [PATCH 12/13] fix typo --- docs/protocol/accounts/object-capabilities.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/protocol/accounts/object-capabilities.md b/docs/protocol/accounts/object-capabilities.md index 45d25ff09..bc9a69620 100644 --- a/docs/protocol/accounts/object-capabilities.md +++ b/docs/protocol/accounts/object-capabilities.md @@ -21,7 +21,7 @@ CACAO enables the ability for one account to authorize another account to constr When combined with ["Sign-in with X"](https://chainagnostic.org/CAIPs/caip-122), CACAO unlocks the ability for blockchain accounts to authorize Ceramic accounts (DIDs) to sign data on their behalf. -This frequently used pattern in Ceramic greatly increases the the usability of user-owned data and public-key cryptography. Thanks to the adoption of blockchain based systems, many users now have the ability to easily sign data in web-based environments using their wallet and blockchain account. +This frequently used pattern in Ceramic greatly increases the usability of user-owned data and public-key cryptography. Thanks to the adoption of blockchain based systems, many users now have the ability to easily sign data in web-based environments using their wallet and blockchain account. ### **Authorizing sessions** From 66999a6ae8a370bdccdab7b5bb0e941ce600a398 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Tue, 3 Oct 2023 10:20:58 +0200 Subject: [PATCH 13/13] fix typo --- docs/run/nodes/nodes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/run/nodes/nodes.md b/docs/run/nodes/nodes.md index 255953f04..9fe2ff236 100644 --- a/docs/run/nodes/nodes.md +++ b/docs/run/nodes/nodes.md @@ -272,7 +272,7 @@ Ceramic nodes rely on IPFS for networking. IPFS nodes connect to each other usin Additionally, when running IPFS the IPFS API port must be accessible by the Ceramic node. The default API port is `5001`. The IPFS node address will then be passed to Ceramic with the `ipfs.host` option in the Ceramic daemon config file. -### **Connect to the mainnnet anchor service** +### **Connect to the mainnet anchor service** For nodes that wish to connect to Ceramic mainnet, the node's IP address will have to be added to the allowlist for the Ceramic Anchor Service node operated by 3BoxLabs. Once you have fully configured your Ceramic node with this guide and have a way to persist its configuration and state, open an issue in the [Ceramic Anchor Allowlist Repo](https://github.com/3box/ceramic-anchor-allowlist) with the public, static *egress* IP address for your Ceramic node, and a brief description of the data persistence setup for the multiaddress, Ceramic State Store, and IPFS Repo. Once your issue is closed, you will be connected to the Ceramic network and the [Ceramic Anchor Service](https://github.com/ceramicnetwork/ceramic-anchor-service).