From b74892a78c2fdf44bbafee4eb742e0b24e72c7c6 Mon Sep 17 00:00:00 2001 From: Justina Petraityte Date: Thu, 22 Aug 2024 13:25:10 +0100 Subject: [PATCH 01/10] update the interact with data guides --- docs/composedb/interact-with-data.mdx | 87 +++++++++++++++++---------- 1 file changed, 56 insertions(+), 31 deletions(-) diff --git a/docs/composedb/interact-with-data.mdx b/docs/composedb/interact-with-data.mdx index 7c06cace..dd39b2ae 100644 --- a/docs/composedb/interact-with-data.mdx +++ b/docs/composedb/interact-with-data.mdx @@ -44,10 +44,10 @@ In the [Create your composite](./create-your-composite.mdx) guide, we fetched tw ```graphql query{ - postIndex(first: 2) { + postsIndex(first: 2) { edges { node { - text + body } } } @@ -67,16 +67,16 @@ You should see a response similar to the one below. Here, nodes correspond to st ```json { "data": { - "postIndex": { + "postsIndex": { "edges": [ { "node": { - "text": "This is my first post." + "text": "A Post created using composites and GraphQL" } }, { "node": { - "text": "My second post about ComposeDB!" + "text": "This is my second post!" } } ] @@ -97,10 +97,10 @@ You have options to retrieve specific records or last `n` indexed records as wel ```graphql query{ - postIndex(last: 3) { + postsIndex(last: 3) { edges { node { - text + body } } } @@ -121,11 +121,15 @@ Let’s say, you would like to create a post and add it to the graph. To do that ```graphql -mutation CreateNewPost($i: CreatePostInput!){ - createPost(input: $i){ - document{ - id - text +mutation CreateNewPost($i: CreatePostsInput!){ + createPosts(input: $i){ + document{ + id + title + body + tag + ranking + created_at } } } @@ -141,7 +145,11 @@ mutation CreateNewPost($i: CreatePostInput!){ { "i": { "content": { - "text": "A Post created using composites and GraphQL" + "title": "New post", + "body": "My new post on Ceramic", + "tag": "User post", + "ranking": 5, + "created_at": "2024-12-03T10:15:30Z" } } } @@ -160,10 +168,14 @@ The result of the query above will be a new document with a unique ID and the co ```json { "data": { - "createPost": { + "createPosts": { "document": { - "id": "kjzl6kcym7w8y9xlffqruh3v7ou1vn11t8203i6te2i3pliizt65ad3vdh5nl4l", - "text": "A Post created using composites and GraphQL" + "id": "kjzl6kcym7w8y5ygh1fyvstbjztd69suybc4ez8bet2hun7jezrc2m0uwg5bm3q", + "title": "New post", + "body": "My new post on Ceramic", + "tag": "User post", + "ranking": 5, + "created_at": "2024-12-03T10:15:30Z" } } } @@ -173,7 +185,8 @@ The result of the query above will be a new document with a unique ID and the co :::note -Stream IDs are unique. The “id” you will see in the response when performing the mutation above will be different. +Stream IDs are unique. The “id” you will see in the response when performing the mutation above will be different. Keep that in mind +as you follow this guide and update the id to the one that you see in your response. ::: @@ -191,11 +204,15 @@ You can find your post’s ID in the response after you ran the `CreateNewPost` **Query:** ```graphql -mutation UpdatePost($i: UpdatePostInput!) { - updatePost(input: $i) { +mutation UpdatePost($i: UpdatePostsInput!) { + updatePosts(input: $i) { document { id - text + title + body + tag + ranking + created_at } } } @@ -208,24 +225,32 @@ mutation UpdatePost($i: UpdatePostInput!) { ```json { "i": { - "id": "kjzl6kcym7w8y9xlffqruh3v7ou1vn11t8203i6te2i3pliizt65ad3vdh5nl4l", + "id": "kjzl6kcym7w8y5ygh1fyvstbjztd69suybc4ez8bet2hun7jezrc2m0uwg5bm3q", "content": { - "text": "My best post!" + "title": "New post", + "body": "My new post on Ceramic using ComposeDB", + "tag": "User post", + "ranking": 5, + "created_at": "2024-12-03T10:15:30Z" } } } ``` -This mutation will update the record with ID `kjzl6kcym7w8y9xlffqruh3v7ou1vn11t8203i6te2i3pliizt65ad3vdh5nl4l`. +This mutation will update the record with ID `kjzl6kcym7w8y5ygh1fyvstbjztd69suybc4ez8bet2hun7jezrc2m0uwg5bm3q`. **Response:** ```json { "data": { - "updatePost": { + "updatePosts": { "document": { - "id": "kjzl6kcym7w8y9xlffqruh3v7ou1vn11t8203i6te2i3pliizt65ad3vdh5nl4l", - "text": "My best post!" + "id": "kjzl6kcym7w8y5ygh1fyvstbjztd69suybc4ez8bet2hun7jezrc2m0uwg5bm3q", + "title": "New post", + "body": "My new post on Ceramic using ComposeDB", + "tag": "User post", + "ranking": 5, + "created_at": "2024-12-03T10:15:30Z" } } } @@ -241,8 +266,8 @@ mutation with the `shouldIndex` option set to `true`, and the post ID as variabl **Query:** ```graphql -mutation EnableIndexingPost($input: EnableIndexingPostInput!) { - enableIndexingPost(input: $input) { +mutation EnableIndexingPost($i: EnableIndexingPostsInput!) { + enableIndexingPosts(input: $i) { document { id } @@ -257,19 +282,19 @@ mutation EnableIndexingPost($input: EnableIndexingPostInput!) { ```json { "i": { - "id": "kjzl6kcym7w8y9xlffqruh3v7ou1vn11t8203i6te2i3pliizt65ad3vdh5nl4l", + "id": "kjzl6kcym7w8y5ygh1fyvstbjztd69suybc4ez8bet2hun7jezrc2m0uwg5bm3q", "shouldIndex": false } } ``` -This mutation will un-index the record with ID `kjzl6kcym7w8y9xlffqruh3v7ou1vn11t8203i6te2i3pliizt65ad3vdh5nl4l`. +This mutation will un-index the record with ID `kjzl6kcym7w8y5ygh1fyvstbjztd69suybc4ez8bet2hun7jezrc2m0uwg5bm3q`. **Response:** ```json { "data": { - "enableIndexingPost": { + "enableIndexingPosts": { "document": null } } From 8d4a0564ee569bede2d04105ed6f361481e1b611 Mon Sep 17 00:00:00 2001 From: Justina Petraityte Date: Thu, 19 Sep 2024 11:48:10 +0100 Subject: [PATCH 02/10] Update wheel-reference.mdx --- docs/wheel/wheel-reference.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/wheel/wheel-reference.mdx b/docs/wheel/wheel-reference.mdx index 3e01390b..f3c7c4cc 100644 --- a/docs/wheel/wheel-reference.mdx +++ b/docs/wheel/wheel-reference.mdx @@ -112,9 +112,9 @@ This section dives deeper into the Ceramic parameters you can configure when you An option to define if IFPS runs in the same compute process as Ceramic. You have two options to choose from: -- Bundled - IPFS running in same compute process as Ceramic; recommended for early prototyping. -- Remote - IPFS running in separate compute process; recommended for production and everything besides early prototyping. - This assumes that you have the IPFS process setup and can provide an IPFS Hostname. +- Remote - IPFS running in separate compute process; recommended for all Ceramic versions that use `ceramic-one`. This configuration requires an IPFS Hostname. Default value is `http://localhost:5101` +- Bundled - IPFS running in same compute process as Ceramic; used only with older Ceramic versions that use Kubo. + ### State Store From 9896893405caf61328f9018857733e3806f251c2 Mon Sep 17 00:00:00 2001 From: Justina Petraityte Date: Thu, 19 Sep 2024 11:51:57 +0100 Subject: [PATCH 03/10] Update create-ceramic-app.mdx --- docs/composedb/create-ceramic-app.mdx | 29 +++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/docs/composedb/create-ceramic-app.mdx b/docs/composedb/create-ceramic-app.mdx index 090b4ff3..83dccbfb 100644 --- a/docs/composedb/create-ceramic-app.mdx +++ b/docs/composedb/create-ceramic-app.mdx @@ -11,6 +11,35 @@ Get up and running quickly with a basic ComposeDB application with one command. - **Node.js v20** - If you are using a different version, please use `nvm` to install Node.js v20 for best results. - **npm v10** - Installed automatically with NodeJS v20 +You will also need to run a ceramic-one node in the background which provides Ceramic +data network access. To set it up, follow the steps below: + +:::note +The instructions below cover the steps for the MacOS-based systems. If you are running on a Linux-based system, you can find the +instructions [here](https://github.com/ceramicnetwork/rust-ceramic?tab=readme-ov-file#linux---debian-based-distributions). +::: + +1. Install the component using [Homebrew](https://brew.sh/): + +```bash +brew install ceramicnetwork/tap/ceramic-one +``` + +2. Start the `ceramic-one` using the following command: +```bash +ceramic-one daemon --network in-memory +``` + +:::note +By default, the command above will spin off a node which connects to a `in-memory`. You can change this behaviour by providing a `--network` flag and specifying a network of your choice. For example: + +```ceramic-one daemon --network testnet-clay``` +::: + +--- + +## Start the ComposeDB example app + You can easily create a simple ComposeDB starter project by using our CLI and running the following command: Date: Thu, 19 Sep 2024 11:54:34 +0100 Subject: [PATCH 04/10] Update server-configurations.mdx --- .../composedb-server/server-configurations.mdx | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/docs/composedb/guides/composedb-server/server-configurations.mdx b/docs/composedb/guides/composedb-server/server-configurations.mdx index e9035251..c67d0bd5 100644 --- a/docs/composedb/guides/composedb-server/server-configurations.mdx +++ b/docs/composedb/guides/composedb-server/server-configurations.mdx @@ -183,18 +183,6 @@ Only Postgres is currently supported for production usage. ::: -## History Sync -By default, Ceramic nodes will only index documents they observe using pubsub messages. In order to index documents created before the node was deployed or configured to index some models, **History Sync** needs to be enabled on the Ceramic node, in the `daemon.config.json` file: - -```json -{ - ... - "indexing": { - ... - "enable-historical-sync": true - } -} -``` ## IPFS Process ### Available Configurations From 0c96c0b8bbf2a3e01bd8d344119e418708346c61 Mon Sep 17 00:00:00 2001 From: Mark Krasner Date: Thu, 17 Oct 2024 11:48:18 -0400 Subject: [PATCH 05/10] Initial save for TACo with composedb example --- .../examples/taco-access-control.mdx | 116 ++++++++++++++++++ sidebars.ts | 5 + 2 files changed, 121 insertions(+) create mode 100644 docs/composedb/examples/taco-access-control.mdx diff --git a/docs/composedb/examples/taco-access-control.mdx b/docs/composedb/examples/taco-access-control.mdx new file mode 100644 index 00000000..312a13cc --- /dev/null +++ b/docs/composedb/examples/taco-access-control.mdx @@ -0,0 +1,116 @@ +# TACo with ComposeDB + +*Store sensitive data on ComposeDB, using decentralized access control to enforce fine-grained decryption rights.* + +This guide explains how to integrate [TACo](https://docs.threshold.network/applications/threshold-access-control) into ComposeDB, which enables the storing and sharing of non-public data on Ceramic. A more detailed version of this tutorial is available [here](https://docs.threshold.network/app-development/threshold-access-control-tac/integration-guides/ceramic-+-taco). + +## TACo Overview + +TACo is a programmable encrypt/decrypt API for applications that handle sensitive user data, without compromising on privacy, security or decentralization. TACo offers a distinct alternative to centralized, permissioned, and TEE-dependent access control services. + +TACo is the first and only end-to-end encrypted data sharing layer in which access to data payloads is always collectively enforced by a distributed group. Today, over 120 service-providers permissionlessly run TACo clients. They independently validate whether a given data request satisfies pre-specified conditions, only then provisioning decryption material fragments for client-side assembly, decryption, and plaintext access. + +TACo offers a flexible access control framework and language, in which access conditions can be configured individually or combined logically. This approach enables developers to chain conditions together and facilitates dynamic access flows. For example, predicting the input to one access condition on the output of a previous access condition can also be programmatically combined with on-chain (and off-chain) authentication methods. + +TACo’s encrypt/decrypt API – [taco-web](https://github.com/nucypher/taco-web) – is straightforward to integrate into any web app and usable in parallel with core Web3 infrastructure like Ceramic. + +### Use Cases + +- **Social networks & Knowledge Bases:** Leverage Ceramic's verifiable credentials and TACo's credential-based decryption to ensure that private user-generated content is only viewable by those who are supposed to see it, and nobody else. + +- **IoT event streams:** Let sensitive data flow from sensors to legitimate recipients, without trusting an intermediary server to handle the routing and harvest metadata. For example, a medical professional can be issued a temporary access token if a patient's wearable output data rises above a certain threshold. + +- **LLM chatbots:** Messages to and from a chatbot should be 100% private, not mined by a UX-providing intermediary. Harness Ceramic's web-scale transaction processing and TACo's per-message encryption granularity to provide a smooth and private experience for users of LLM interfaces. + +## Example Application & Repo + +The "TACo with ComposeDB Message Board [Application](https://github.com/nucypher/taco-composedb/tree/main)" is provided as an example and reference for developers – illustrating how TACo and ComposeDB can be combined in a browser-based messaging app. Once installed, a simple UI shows how messages can be encrypted by data producers with access conditions embedded, and how data consumers can view messages *only* if they satisfy those conditions. Launching the demo also involves running a local Ceramic node, to which TACo-encrypted messages are saved and immediately queryable by data requestors. + +The following sections explain the core components of TACo’s access control system – access conditions, encryption, and decryption. + +### Specifying access conditions & authentication methods + +There are two ways in which a recipient, or data consumer, must prove their right to access the private data – (1) authentication and (2) condition fulfillment. The data producer must specify the authentication methods and condition(s) before encrypting the private data, as this configuration is embedded alongside the encrypted payload. + +In the example snippet below, we are using RPC conditions. The function will check the *data consumer’s* Ethereum wallet balance, which they prove ownership of via the chosen authentication method – in this case via a EIP4361 (Sign-In with Ethereum) message. Note that this message has already been solicited and utilized by the application, analogous to single-sign-on functionality. This setup is the same as in the demo code above and can be viewed directly in the [repo](https://github.com/nucypher/taco-composedb/blob/main/src/fragments/chatinputbox.tsx#L26-L34). + +```TypeScript +import { conditions } from "@nucypher/taco"; + +const rpcCondition = new conditions.base.rpc.RpcCondition({ + chain: 80002, + method: 'eth_getBalance', + parameters: [':userAddressExternalEIP4361'], + returnValueTest: { + comparator: '>', + value: 0, + }, +}); +``` + +### Encrypting & saving the data + +To complete the encryption step, the following are added as arguments: +a. `domain` – testnet or mainnet +b. `ritualId` – the ID of the cohort of TACo nodes who will collectively manage access to the data +c. a standard web3 provider + +The output of this function is a payload containing both the encrypted data and embedded metadata necessary for a qualifying data consumer to access the plaintext message. + +```TypeScript +import { initialize, encrypt, conditions, domains, toHexString } from '@nucypher/taco'; +import { ethers } from "ethers"; + +await initialize(); + +const web3Provider = new ethers.providers.Web3Provider(window.ethereum); +const ritualId = 0 +const message = "I cannot trust a centralized access control layer with this message."; +const messageKit = await encrypt( + web3Provider, + domains.TESTNET, + Message, + rpcCondition, + ritualId, + web3Provider.getSigner() +); +const encryptedMessageHex = toHexString(messageKit.toBytes()); +``` + +### Querying & decrypting the data + +Data consumers interact with the TACo API via the `decrypt` function. They include the following arguments: + +a. Provider +b. Domain +c. EncryptedMessage +d. ConditionContext + +The conditionContext is a way for developers to programmatically provide required data consumer authentication methods mapped to specific access conditions – all at decryption time. + +```TypeScript +import {conditions, decrypt, Domain, encrypt, ThresholdMessageKit} from '@nucypher/taco'; +import {ethers} from "ethers"; + +export async function decryptWithTACo( + encryptedMessage: ThresholdMessageKit, + domain: Domain, + conditionContext?: conditions.context.ConditionContext +): Promise { + const provider = new ethers.providers.Web3Provider(window.ethereum); + return await decrypt( + provider, + domain, + encryptedMessage, + conditionContext, + ) +} +``` + +Note that the EIP4361 authentication data required to validate the user address (within the condition) is supplied via the `conditionContext` object. To understand this component better, check out the demo [repo](https://github.com/nucypher/taco-composedb/blob/main/src/fragments/chatcontent.tsx#L47). + +### Using ComposeDB & TACo in production + +For Ceramic, connect to Mainnet (`domains.MAINNET`). + +For TACo, a funded Mainnet ritualID is required – this connects the encrypt/decrypt API to a cohort of independently operated nodes and corresponds to a DKG public key generated by independent parties. A dedicated ritualID for Ceramic + TACo projects will be sponsored soon. Watch for updates here. diff --git a/sidebars.ts b/sidebars.ts index fa299d2a..3f6abdc5 100644 --- a/sidebars.ts +++ b/sidebars.ts @@ -241,6 +241,11 @@ const sidebars: SidebarsConfig = { type: "doc", id: "composedb/examples/verifiable-credentials", label: "Verifiable Credentials" + }, + { + type: "doc", + id: "composedb/examples/taco-access-control", + label: "TACo with ComposeDB" } ] }, From 54500ac44db79a86d4c1a74ce5a68c14dbdbc889 Mon Sep 17 00:00:00 2001 From: Mark Krasner <70119343+mzkrasner@users.noreply.github.com> Date: Mon, 21 Oct 2024 12:16:51 -0400 Subject: [PATCH 06/10] TACo introduction summary edits Co-authored-by: Arjun Hassard --- docs/composedb/examples/taco-access-control.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/composedb/examples/taco-access-control.mdx b/docs/composedb/examples/taco-access-control.mdx index 312a13cc..9ca7fac8 100644 --- a/docs/composedb/examples/taco-access-control.mdx +++ b/docs/composedb/examples/taco-access-control.mdx @@ -10,7 +10,8 @@ TACo is a programmable encrypt/decrypt API for applications that handle sensitiv TACo is the first and only end-to-end encrypted data sharing layer in which access to data payloads is always collectively enforced by a distributed group. Today, over 120 service-providers permissionlessly run TACo clients. They independently validate whether a given data request satisfies pre-specified conditions, only then provisioning decryption material fragments for client-side assembly, decryption, and plaintext access. -TACo offers a flexible access control framework and language, in which access conditions can be configured individually or combined logically. This approach enables developers to chain conditions together and facilitates dynamic access flows. For example, predicting the input to one access condition on the output of a previous access condition can also be programmatically combined with on-chain (and off-chain) authentication methods. +TACo offers a flexible access control framework and language, in which access conditions can be configured individually and combined logically. Developers can compose dynamic access workflows for their users – for example, using +the sequential conditions feature to predicate the input to a given access condition on the output of a previous condition or call. Conditions may also be programmatically combined with both on-chain and off-chain authentication methods. TACo’s encrypt/decrypt API – [taco-web](https://github.com/nucypher/taco-web) – is straightforward to integrate into any web app and usable in parallel with core Web3 infrastructure like Ceramic. From 2b0ffe6bfc5a2753fc244a1f75f611b7cb7c414a Mon Sep 17 00:00:00 2001 From: Mark Krasner <70119343+mzkrasner@users.noreply.github.com> Date: Mon, 21 Oct 2024 12:17:35 -0400 Subject: [PATCH 07/10] Better specificity edits around conditionContext Co-authored-by: Arjun Hassard --- docs/composedb/examples/taco-access-control.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/composedb/examples/taco-access-control.mdx b/docs/composedb/examples/taco-access-control.mdx index 9ca7fac8..49cc69de 100644 --- a/docs/composedb/examples/taco-access-control.mdx +++ b/docs/composedb/examples/taco-access-control.mdx @@ -87,7 +87,7 @@ b. Domain c. EncryptedMessage d. ConditionContext -The conditionContext is a way for developers to programmatically provide required data consumer authentication methods mapped to specific access conditions – all at decryption time. +`conditionContext` is a way for developers to programmatically map methods for authenticating a data consumer to specific access conditions – all executable at decryption time. For example, if the condition involves proving ownership of a social account, authenticate via OAuth. ```TypeScript import {conditions, decrypt, Domain, encrypt, ThresholdMessageKit} from '@nucypher/taco'; From d0846f899ae10c253f34e1948624bc624e764fde Mon Sep 17 00:00:00 2001 From: Mark Krasner <70119343+mzkrasner@users.noreply.github.com> Date: Mon, 21 Oct 2024 12:18:23 -0400 Subject: [PATCH 08/10] Better IoT use case summary Co-authored-by: Arjun Hassard --- docs/composedb/examples/taco-access-control.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/composedb/examples/taco-access-control.mdx b/docs/composedb/examples/taco-access-control.mdx index 49cc69de..1f0fd536 100644 --- a/docs/composedb/examples/taco-access-control.mdx +++ b/docs/composedb/examples/taco-access-control.mdx @@ -19,7 +19,7 @@ TACo’s encrypt/decrypt API – [taco-web](https://github.com/nucypher/taco-web - **Social networks & Knowledge Bases:** Leverage Ceramic's verifiable credentials and TACo's credential-based decryption to ensure that private user-generated content is only viewable by those who are supposed to see it, and nobody else. -- **IoT event streams:** Let sensitive data flow from sensors to legitimate recipients, without trusting an intermediary server to handle the routing and harvest metadata. For example, a medical professional can be issued a temporary access token if a patient's wearable output data rises above a certain threshold. +- **IoT event streams:** Let data flow from sensors to legitimate recipients, without trusting an intermediary server to handle the routing and harvest sensitive (meta)data. For example, a medical professional can be issued a temporary access token if the output data from a patient's wearable device rises above a certain threshold. - **LLM chatbots:** Messages to and from a chatbot should be 100% private, not mined by a UX-providing intermediary. Harness Ceramic's web-scale transaction processing and TACo's per-message encryption granularity to provide a smooth and private experience for users of LLM interfaces. From d65dda49939ee7fb80c10ede1c0e26e4267f7615 Mon Sep 17 00:00:00 2001 From: Mark Krasner <70119343+mzkrasner@users.noreply.github.com> Date: Mon, 21 Oct 2024 12:19:08 -0400 Subject: [PATCH 09/10] Verbiage clarity edits for LLM chatbots use case Co-authored-by: Arjun Hassard --- docs/composedb/examples/taco-access-control.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/composedb/examples/taco-access-control.mdx b/docs/composedb/examples/taco-access-control.mdx index 1f0fd536..c551149a 100644 --- a/docs/composedb/examples/taco-access-control.mdx +++ b/docs/composedb/examples/taco-access-control.mdx @@ -21,7 +21,7 @@ TACo’s encrypt/decrypt API – [taco-web](https://github.com/nucypher/taco-web - **IoT event streams:** Let data flow from sensors to legitimate recipients, without trusting an intermediary server to handle the routing and harvest sensitive (meta)data. For example, a medical professional can be issued a temporary access token if the output data from a patient's wearable device rises above a certain threshold. -- **LLM chatbots:** Messages to and from a chatbot should be 100% private, not mined by a UX-providing intermediary. Harness Ceramic's web-scale transaction processing and TACo's per-message encryption granularity to provide a smooth and private experience for users of LLM interfaces. +- **LLM chatbots:** Messages to and from a chatbot should be 100% private, not mined by a UX-providing intermediary. Harness Ceramic's web-scale transaction processing and TACo's per-message encryption/condition granularity to provide a smooth and safe experience for users of LLM interfaces. ## Example Application & Repo From 617752afda1b89b69d76af4b48ae700baea51a0d Mon Sep 17 00:00:00 2001 From: Mark Krasner <70119343+mzkrasner@users.noreply.github.com> Date: Mon, 21 Oct 2024 12:19:48 -0400 Subject: [PATCH 10/10] Slight formatting modifications for method arguments Co-authored-by: Arjun Hassard --- docs/composedb/examples/taco-access-control.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/composedb/examples/taco-access-control.mdx b/docs/composedb/examples/taco-access-control.mdx index c551149a..3504533f 100644 --- a/docs/composedb/examples/taco-access-control.mdx +++ b/docs/composedb/examples/taco-access-control.mdx @@ -82,10 +82,10 @@ const encryptedMessageHex = toHexString(messageKit.toBytes()); Data consumers interact with the TACo API via the `decrypt` function. They include the following arguments: -a. Provider -b. Domain -c. EncryptedMessage -d. ConditionContext +a. `provider` +b. `domain` +c. `encryptedMessage` +d. `conditionContext` `conditionContext` is a way for developers to programmatically map methods for authenticating a data consumer to specific access conditions – all executable at decryption time. For example, if the condition involves proving ownership of a social account, authenticate via OAuth.