Skip to content
Key Concepts

Key Concepts

This section explains several key concepts of DataverseOS.

Sign-In with Ethereum (SIWE)

Sign-In with Ethereum is a feature that allows users to authenticate and access various off-chain services using their blockchain wallet addresses. Similar to other popular social login options like "Sign-In with Google" or "Sign-In with Facebook," "Sign-In with Ethereum" leverages the blockchain network for authentication purposes.

By utilizing this authentication method, DataverseOS provides a secure, user-centric method for identity and data access authorization.

Resource

OS defines several kinds of resources that can be considered as composable modules in a personal computer. These resources serve different system functions, such as storage, computation, and more. Developers can request access to these resources from users.

Ceramic Database

The OS is storing data on Ceramic ComposeDB - a decentralized graph database built on Ceramic network. And we are using SIWE to authenticate users and authorize their access to data resources. A SIWE message may look like this:

The Resources in this message content specifies the tables in ceramic database that you are giving access to. Each ceramic://model refers to a table.

Lit Action

Coming soon...

Data model

type post @createModel(accountRelation: LIST, description: "post") {
  text: String @string(maxLength: 300000000)
  images: [String] @list(maxLength: 10000000) @string(maxLength: 2000000)
  videos: [String] @list(maxLength: 10000000) @string(maxLength: 2000000)
  createdAt: DateTime!
  updatedAt: DateTime!
}

A data model is a GraphQL schema that defines a database table structure. For example, the above schema defines a post table with the following columns:

post table:

column_namedata_typeis_nullable
textStringYES
imagesArray<String>YES
videosArray<String>YES
createdAtDataTimeNO
updatedAtDateTimeNO

Data stream

You can create data streams under a data model. It is like creating records in a database table. Each data stream has a unique streamId and you can load, update, encrypt, and delete the data stream using the streamId and APIs here. What is different from a traditional database table is that each record belongs to the specific DID who creates it. For example, if you create a data stream under the post model:

{
  "text": "hello",
  "images": ["https://bafk..."],
  "videos": [],
  "createdAt": "2023-06-27T09:59:20.915Z",
  "updatedAt": "2023-06-27T09:59:20.915Z"
}

After creating the data stream, the post table will have the following record:

and only your DID can write to this record.

Index file

Based on data model and data stream, we fulfilled a Web Native File System(WNFS). The WNFS contains 3 types of files. An index file is a data stream created under any data model, whether it's defined by our system or created by applications. We create a compatible API layer to wrap these data streams, for each data stream, we create an index file to store the metadata of the data stream. Thus, data generated by different applications can be accessed in a unified way. For example, a tweet, a blog post, and a photo can be treated in the same way as index files in the WNFS.

Action file

Besides, we designed an action file to store the activitity history between user and an index file. For example, if you like a tweet, the action file will record this action. If you comment on a tweet, the action file will record the comment. The action file is a data stream created under the action model. An action file links to a specific index file and has multiple attributes. Currently we support 5 types of actions: like, comment, share, unlock, receive.

Bare file

Bare file are special data streams that are not created under any data model. They are used to store data that is not directly uploaded to our network. For example, if you upload a photo to IPFS, you can create a bare file to store the IPFS hash.

Dapp table

Dapp table is an application registry table to record which data models belong to a specific dApp. For example, if you have a dApp dTwitter and create data model post and comment for it, these 2 models belong to dTwitter. Only dTwitter can create data streams under these 2 models. The Dapp table is a table to record this relationship and prevent other dApps (maybe bad) from accessing data resources of dTwitter.

  • private key: developer's private key to administrate a dApp and (if the dApp is in production) the self-hosted ceramic node.
  • dApp: an application on DataverseOS.
  • data model: a GraphQL schema that defines a database table structure.
  • schema: one model could have multiple versions of schemas. Each schema has a unique commitId.
DApp StoreCreate Dataverse App