|
| 1 | +# TACo with ComposeDB |
| 2 | + |
| 3 | +*Store sensitive data on ComposeDB, using decentralized access control to enforce fine-grained decryption rights.* |
| 4 | + |
| 5 | +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). |
| 6 | + |
| 7 | +## TACo Overview |
| 8 | + |
| 9 | +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. |
| 10 | + |
| 11 | +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. |
| 12 | + |
| 13 | +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 |
| 14 | +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. |
| 15 | + |
| 16 | +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. |
| 17 | + |
| 18 | +### Use Cases |
| 19 | + |
| 20 | +- **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. |
| 21 | + |
| 22 | +- **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. |
| 23 | + |
| 24 | +- **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. |
| 25 | + |
| 26 | +## Example Application & Repo |
| 27 | + |
| 28 | +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. |
| 29 | + |
| 30 | +The following sections explain the core components of TACo’s access control system – access conditions, encryption, and decryption. |
| 31 | + |
| 32 | +### Specifying access conditions & authentication methods |
| 33 | + |
| 34 | +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. |
| 35 | + |
| 36 | +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). |
| 37 | + |
| 38 | +```TypeScript |
| 39 | +import { conditions } from "@nucypher/taco"; |
| 40 | + |
| 41 | +const rpcCondition = new conditions.base.rpc.RpcCondition({ |
| 42 | + chain: 80002, |
| 43 | + method: 'eth_getBalance', |
| 44 | + parameters: [':userAddressExternalEIP4361'], |
| 45 | + returnValueTest: { |
| 46 | + comparator: '>', |
| 47 | + value: 0, |
| 48 | + }, |
| 49 | +}); |
| 50 | +``` |
| 51 | + |
| 52 | +### Encrypting & saving the data |
| 53 | + |
| 54 | +To complete the encryption step, the following are added as arguments: |
| 55 | +a. `domain` – testnet or mainnet |
| 56 | +b. `ritualId` – the ID of the cohort of TACo nodes who will collectively manage access to the data |
| 57 | +c. a standard web3 provider |
| 58 | + |
| 59 | +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. |
| 60 | + |
| 61 | +```TypeScript |
| 62 | +import { initialize, encrypt, conditions, domains, toHexString } from '@nucypher/taco'; |
| 63 | +import { ethers } from "ethers"; |
| 64 | + |
| 65 | +await initialize(); |
| 66 | + |
| 67 | +const web3Provider = new ethers.providers.Web3Provider(window.ethereum); |
| 68 | +const ritualId = 0 |
| 69 | +const message = "I cannot trust a centralized access control layer with this message."; |
| 70 | +const messageKit = await encrypt( |
| 71 | + web3Provider, |
| 72 | + domains.TESTNET, |
| 73 | + Message, |
| 74 | + rpcCondition, |
| 75 | + ritualId, |
| 76 | + web3Provider.getSigner() |
| 77 | +); |
| 78 | +const encryptedMessageHex = toHexString(messageKit.toBytes()); |
| 79 | +``` |
| 80 | + |
| 81 | +### Querying & decrypting the data |
| 82 | + |
| 83 | +Data consumers interact with the TACo API via the `decrypt` function. They include the following arguments: |
| 84 | + |
| 85 | +a. `provider` |
| 86 | +b. `domain` |
| 87 | +c. `encryptedMessage` |
| 88 | +d. `conditionContext` |
| 89 | + |
| 90 | +`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. |
| 91 | + |
| 92 | +```TypeScript |
| 93 | +import {conditions, decrypt, Domain, encrypt, ThresholdMessageKit} from '@nucypher/taco'; |
| 94 | +import {ethers} from "ethers"; |
| 95 | + |
| 96 | +export async function decryptWithTACo( |
| 97 | + encryptedMessage: ThresholdMessageKit, |
| 98 | + domain: Domain, |
| 99 | + conditionContext?: conditions.context.ConditionContext |
| 100 | +): Promise<Uint8Array> { |
| 101 | + const provider = new ethers.providers.Web3Provider(window.ethereum); |
| 102 | + return await decrypt( |
| 103 | + provider, |
| 104 | + domain, |
| 105 | + encryptedMessage, |
| 106 | + conditionContext, |
| 107 | + ) |
| 108 | +} |
| 109 | +``` |
| 110 | + |
| 111 | +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). |
| 112 | + |
| 113 | +### Using ComposeDB & TACo in production |
| 114 | + |
| 115 | +For Ceramic, connect to Mainnet (`domains.MAINNET`). |
| 116 | + |
| 117 | +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. |
0 commit comments