Cedalio is a database that meticulously tracks every alteration in application data, upholding an immutable and verifiable traceable record over time. Companies can leverage Cedalio to store critical information related to their key applications, thereby reducing fraud while enhancing transparency and auditability.
We created Cedalio to make it easier for developers to achieve these goals.
Without Cedalio, developers would need to manually create databases, spin up their own backend, manage their infrastructure, connect off-chain databases with the smart contracts associated with it, and so on.
With Cedalio, developers can easily create and access a serverless database using GraphQL. No need to manage infrastructure or implement a backend. Furthermore, we’ve developed a TypeScript SDK that works both on your clients and server side application.
Today, companies that use Cedalio have something in common: they need to maintain an untampered historical record of crucial business data.
We’ve seen success in:
- Climate Tech: Records of carbon emissions for accounting purposes.
- Supply Chain: Overview of agricultural output, nutrition metrics, and quality standards.
- Fintech: Financial transactions and history for personalized user vaults.
- AI Infrastructure: Inputs and sources of information for training AI models with proofable sources.
- Health Tech: Patients’ health information for individual vaults of data.
Ok but, how does Cedalio work?
Our platform uses blockchain technology to build apps, and enables information verifiability that is auditable by default. The platform architecture is designed in a way that developers and users can reap the benefits of decentralized data storage while maintaining the performance and convenience associated with conventional databases.
Cedalio’s architecture consists of 7 steps of data management.
First, users kick things off with a GraphQL request, a precise order of data needs, which must carry the right authentication credentials (JWT) to get past our security gates.
Once validated, the request’s legitimacy and access rights are double-checked against on-chain smart contracts, our platform’s rulebook. If all checks out, the request then transforms into actionable tasks for our database.
As tasks execute, every move is meticulously recorded in an operation log, ensuring a traceable trail of every data interaction. These logs, stored on the IPFS network, are periodically committed onto the database’s smart-contract for transparency and accountability.
What can you build?
Cedalio presents two distinct approaches: one database per user and one database per organization.
One database per organization approach
This approach is suitable for a scenario where a food company produces goods and wants to ensure ingredient alignment with ESG metrics for final client visibility.
Cedalio utilizes Wallets for managing Database ownership and Access Control Layer on-chain. For users who prefer not to manage wallets, Privy takes care of this task.
1. Define your information schema
This step entails defining the schema representing the production process and ingredients of the client. A simplified schema is provided here:
type User @model {
firstName: String
lastName: String
email: Email
avatar: URL
}
type Organization @model{
name: String
address: String
owner: User
logo: URL
}
type Supplier @model{
organization: Organization
"This is the Harvesting method. Its only defined HandPickcing but we can add more in the future."
harvestingMethod: HarvestingMethod @relation(name:"harvestMethod")
harvestingMethodTarget: HarvestingMethod @relation(name:"harvestMethodTarget")
"Distance in Km"
distanceTransportation: Float
distanceTransportationTarget: Float
"Only include the transportation emition"
estimatedEmissions: Float
estimatedEmissionsTarget: Float
}
enum HarvestingMethod {
HANDPICKING
}2. Create a project and deploy a database in our studio
Then, access our Studio, establish a project, upload the chosen schema, and define the Access Mode. In this instance, Public-Read access is selected to enable information reading, with write privileges limited to the company.
Create a database, during project creation or, you can also generate a database within the project overview. A wallet is required to own the database (no token balance needed).
3. Kickoff the application’s codebase
For this demonstration, it is recommended to use Next.js, deployed on Vercel. Once this is complete, download our SDK.
npm i @cedalio/sdk-js4. Authentication
Cedalio supports Privy, Lens JWT, and the generation of a JWT for a specific address via our Gateway.
For getting a valid JWT with our SDK you need to execute:
const response = await cedalioSdk.login({ address: 'The wallet address' });The Wallet Address is the same as the one that you already used for deploying the Database.
5. Manage Access Control Lists (ACLs)
You can find ACL management streamlines in our SDK. For instance, it enables granting a Wallet Address permissions to read or write distinct objects, a privilege solely managed by the database owner.
const result = await cedalioSdk.setAccessRules({
deploymentId: 'Your deployment id',
rules: [
// Global permission
{
accessControl: 'PUBLIC_READ' // Can also be 'PRIVATE' or 'PUBLIC'
},
// Per-user permission
{
accessControl: 'ALLOW_FULL_ACCESS',
address // User address for the rule to be applied to.
},
// Field-level permission
{
accessControl: 'RULE_BASED',
address, // User address for the rule to be applied to.
objectTypeName: 'User', // Database model name
fields: [{
fieldName: 'id'; // Field under the objectTypeName model
read: true;
write: false;
}]
}
]
});6. Execute operations
Accessing the database is done through the GraphQL API. We will launch support for TypeScript API soon. As for now, we recommend using Apollo Client.
Here is an example of a mutation for creating a user. You can get the endpoint from the studio and should look like this:
https://${CEDALIO_PROJECT_ID}.gtw.cedalio.io/deployments/${deploymentId}/graphqlmutation {
userCreate(
input: {
firstName: "Nixon"
lastName: "Cedalio"
email: "nico@cedalio.com"
}
) {
user {
id
}
}
}That’s it, now you are ready to go and you can now execute all the operations that you want and they will all be verifiable.
One database per user approach
Imagine a scenario where data ownership is paramount, such as a decentralized social network or an application that stores patient information.
To better illustrate how the API works for a database per user scenario, let’s checkout this simple To-Do App. The process mirrors the previous example, but in this case, the database is deployed from the app itself.
In order to get ready, we will deploy a new database every time the User Signups to the To-Do App. To do this, we will run:
const response = await cedalioSdk.waitForDatabaseDeployment({
deploymentId: 'The deployment id'
});Then, we can interact with the database accessing this endpoint:
https://${CEDALIO_PROJECT_ID}.gtw.cedalio.io/deployments/${deploymentId}/graphqlIn this setup, each user possesses their individual ToDo Database, ensuring complete isolation and user ownership. This approach guarantees that users’ data remains distinct from one another.
It is also possible to enable scenarios where users intend to share certain ToDos with others. To enable such sharing, users must use the Access Control functionality within the SDK. Through this mechanism, they will be able to grant specific users access to designated ToDos, allowing collaboration and flexibility within the application.
Try it out!
If you are looking to have verifiable databases, now you are ready to sign up for the Studio. For further information, visit our documentation.
