Using OrbisDB to write data should feel just as natural as it does with a Web2 database.

Flow of data

OrbisDB is built on top of Ceramic, a decentralized event store. In order to inherit Ceramic’s properties such as data ownership, integrity and verifiability, we use Ceramic as our ingestion layer.

When writing data to OrbisDB, end users interact with Ceramic directly, making them the true controllers, with nobody else being able to modify the data.

When writing data, you need to specify the Model (link) to which the data will adhere to.

Once written to Ceramic, all OrbisDB instances subcribed to a Model used will get a notification and begin the indexing process. This includes Context (link) checks, validation done by Plugins (link), etc.

Indexed data is then queried from OrbisDB directly, but is linked to the underlying Ceramic data via the Stream ID.

INSERT in OrbisDB

Two main sources of writes exists in OrbisDB: users and plugins.

Users

This is the main way data gets written to OrbisDB, as it represents your end users. Thanks to the SDK abstraction, there’s a simple ORM-like approach to writing data.

Before writing data, users need to be authenticated - check out Authentication (link) part of our SDK Reference.

In order to write the data, you’ll be using insert and insertBulk methods (link).

Plugins

Plugins have the ability to generate data on their own. This data is signed by your node and can be used for purposes such as bringing data from outside sources (APIs, webhooks) or generating reports based on certain rules.

Example Plugins using this functionality: CSV Uploader and API Data Source.

To learn more about Plugins click here (link).

Encrypted data

Since OrbisDB uses Ceramic as it’s ingestion layer, all data needs to be encrypted client-side - before being written to Ceramic.

OrbisDB will respect the Model (link) definition when indexing the data, however, it will be indexed as-is. No decryption attempts will be made.