feat: add ceramic one, orbis db updates

Author: dtbuchholz

docs/orbisdb/introduction/README.mdx

@@ -0,0 +1,46 @@
+---
+title: Overview
+description: Open-source relational database built on top of Ceramic.
+---
+
+OrbisDB is a fully open-source relational database built on top of Ceramic, a decentralized event
+store. It inherits data ownership, composability and decentralized properties of Ceramic, while
+providing a highly scalable way of querying data via SQL, GraphQL and a built-in Dashboard.
+
+## Features
+
+- Easy setup
+- Scalability
+- Decentralized
+- Composable
+- Contextualized
+- Data ownership
+- Customizable
+- PostgreSQL
+- GraphQL
+
+## Motivation
+
+OrbisDB is a successor of Orbis, an open social protocol. The experience of building a user and
+developer friendly open social protocol gave us insights into existing solutions and their
+limitations.
+
+Most web3 database solutions today come with trade-offs such as high gas costs, scalability issues
+or a completely new architecture and developer experience.
+
+OrbisDB, on other hand, builds on top of existing
+[solutions and protocols](/docs/orbisdb/managing-data). This allows us to focus on the core product,
+without reinventing existing foundations. It also benefits from the existing vast ecosystems.
+
+Since nobody can predict all the use cases, OrbisDB comes with plugins, allowing anyone to build and
+extend core functionality, expose new API routes or customize the way data is being validated and
+stored.
+
+## Use cases
+
+- Social platform
+- Forum
+- Web apps
+- DeSci
+- DePin
+- Data pipelines

docs/orbisdb/introduction/architecture.mdx

@@ -0,0 +1,80 @@
+---
+title: Architecture
+description:
+  OrbisDB builds on top of proven foundations, utilizing open-source projects, standards and
+  protocols.
+---
+
+OrbisDB builds on top of proven foundations, utilizing open-source projects, standards and
+protocols.
+
+## Ceramic (write)
+
+Ceramic is a decentralized event store with composability and data ownership at its core. It can be
+compared to Kafka in the Web2 stack. The protocol is purpose-built for data, allowing for higher
+scalability and lower costs.
+
+To find out more about Ceramic, check out the docs.
+
+### Streams
+
+Each Ceramic stream represents a row in OrbisDB. It contains all commits (modifications) done to the
+data since the initial creation. This is done in the form of Events.
+
+### Models
+
+Ceramic Models dictate the way data needs to be structured, providing composability out of the box.
+Any application can consume the data based on the Model definition, knowing it will be valid. Each
+Model is treated as a subscription topic and represented as a unique Table in OrbisDB.
+
+Read more about Models [here](/docs/orbisdb/managing-data/models).
+
+### IPFS
+
+IPFS (and IPLD) are powering Ceramic's data storage, providing a universal data model and P2P cold
+storage.
+
+### DID
+
+Ceramic utilizes [DIDs](/docs/orbisdb/managing-data/accounts) - decentralized identifiers. Any data
+coming through Ceramic needs to be signed by the end user. Creators have the sole ownership over
+their data.
+
+## PostgreSQL (read)
+
+The most famous open-source database sits at the core of OrbisDB. Choosing PostgreSQL allows OrbisDB
+to expose a familiar query interface. It also brings an existing ecosystem, bundled with thousands
+of extensions and services.
+
+## OrbisDB Node (orchestrate)
+
+OrbisDB Node runs on top of Ceramic and PostgreSQL, indexing data and exposing an API to query it.
+It subscribes to Ceramic's events via SSE, ingesting, filtering and storing data based on the rules
+defined by the OrbisDB Node owner.
+
+### Dashboard
+
+OrbisDB Dashboard is a hosted UI that allows anyone to configure and manage their node with no
+server or infrastructure knowledge required.
+
+### Plugins (customize)
+
+Nobody can predict all the use cases, so we made sure to include a robust plugin framework. This
+allows anyone to tap into the existing ecosystem of plugins or build new ones to make OrbisDB truly
+theirs. Plugins are used to validate and enrich data, do post-processing (such as webhooks,
+notifications, and emails) and expose API routes.
+
+### Writing data
+
+1. End user creates and signs the data (SDK)
+2. The data is sent to Ceramic by the end user directly (SDK)
+3. OrbisDB picks up and processes Ceramic events
+4. Plugins are used to validate and enrich the data
+5. If the data passes all the checks, its then organized and stored in PostgreSQL
+6. Plugins get the final state of data, allowing them to do post-processing operations
+
+### Reading data
+
+1. User interacts with the OrbisDB directly (SDK)
+2. OrbisDB handles permissions and locates the data
+3. Data gets loaded from the database and returned to the user

docs/orbisdb/introduction/quickstart.mdx

@@ -0,0 +1,49 @@
+---
+title: Quickstart
+description: A list of resources to get you started with decentralized data today.
+---
+
+A list of resources to get you started with decentralized data today.
+
+## OrbisDB `Studio`
+
+OrbisDB Studio is a shared node managed by the team behind OrbisDB. You can start exploring OrbisDB
+with no downloads, setup or a single line of code. Check out our
+[Managed section](/docs/orbisdb/setting-up/managed-studio) or
+[visit the Studio](https://studio.useorbis.com/).
+
+## OrbisDB `Node`
+
+You can find the source code of OrbisDB nodes [in our Github](https://github.com/OrbisWeb3/orbisdb).
+It's MIT licensed. Learn how to set up your node for local development or in the cloud in our
+[Setting up section](/docs/orbisdb/setting-up).
+
+## OrbisDB `Dashboard`
+
+A Data dashboard for node management.
+
+## OrbisDB `SDK`
+
+To read and write data programmatically, you need an SDK. Check out the
+[source code](https://github.com/OrbisWeb3/db-sdk) or the
+[package](https://www.npmjs.com/package/@useorbis/db-sdk) and install it using your favorite package
+manager. Quickstart your decentralized data journey with our
+[SDK Reference](/docs/orbisdb/sdk-reference).
+
+### Installing the SDK
+
+You can use your package manager of choice, in this case we'll be using NPM.
+
+```bash
+npm install @useorbis/db-sdk
+```
+
+## Resources
+
+Learn more about OrbisDB's [Architecture](/docs/orbisdb/introduction/architecture) or check out
+[how reading and writing data works](/docs/orbisdb/managing-data).
+
+## Docker **`Coming soon`**
+
+We are working on Docker images to simplify the setup process with prebuilt binaries and bundled
+options.

docs/orbisdb/managing-data/README.mdx

@@ -0,0 +1,54 @@
+---
+title: Managing data
+description: Learn how to manage data in OrbisDB.
+---
+
+OrbisDB is built on top of decentralized components such as DIDs and Models. Despite being new,
+these concepts have been made easy to use thanks to OrbisDB abstractions and a Web2-like DX.
+
+## Accounts (DIDs)
+
+OrbisDB utilizes decentralized identifiers (DIDs) for account management. Each entry in the OrbisDB
+is verifiably owned by its original author - a trait inherited from Ceramic. DIDs bring this to
+another level, allowing users to own their identity in full. They are self-verifiable, so you can
+prove your identity (and data ownership) with no 3rd parties involved.
+
+Learn more in the [Accounts section](/docs/orbisdb/managing-data/accounts).
+
+## Models (Tables)
+
+Composable data requires rules. Applications and users need to understand the data to consume it.
+Models are a way for you to define your OrbisDB tables using standard JSON Schema. This helps
+OrbisDB build out the tables, indexes and relations required. It also allows you to control the data
+format, structure and rules - making it easy for anyone to consume.
+
+Find out how to create your first Table in our [Models section](/docs/orbisdb/managing-data/models).
+
+## Contexts (Spaces)
+
+Data in today's world is already complex enough. However, bringing data to an open and composable
+network is a challenge in itself. Contexts and Sub-Contexts are an OrbisDB (and Ceramic) native way
+of organizing data. Think of them as separate "Spaces" in your OrbisDB. They help OrbisDB sift
+through data to index, but also allow isolation for things such as plugins.
+
+Learn how data organization works in our [Contexts section](/docs/orbisdb/managing-data/contexts).
+
+## Queries
+
+We were determined to bring a familiar developer experience to the web3. This is one of the reasons
+our indexing is backed by PostgreSQL. However, there's more to it than just the choice of
+technologies. Our SDK methods should feel just as familiar, whether you're interacting with our
+underlying data network (Ceramic) or OrbisDB directly.
+
+### INSERT & UPDATE
+
+Writing data to a decentralized data network is one function call away - literally. Learn how
+`INSERTs` and `UPDATEs` work in OrbisDB in our [Writing](/docs/orbisdb/managing-data/insert) and
+[Updating](/docs/orbisdb/managing-data/update) data sections.
+
+### SELECT
+
+When querying already-indexed data, you're interfacing with OrbisDB directly. Whether you prefer a
+query builder, raw SQL or GraphQL - OrbisDB got you covered.
+
+Check out the full [SELECT guide here](/docs/orbisdb/managing-data/select).

docs/orbisdb/managing-data/accounts.mdx

@@ -0,0 +1,121 @@
+---
+title: Accounts (DIDs)
+description: Understand how OrbisDB uses DIDs to manage data ownership.
+---
+
+One of OrbisDB's main features is data ownership - each entry in OrbisDB is verifiably owned by the
+end user, the original author.
+
+## Decentralized Identifiers
+
+OrbisDB inherits its data ownership properties from Ceramic, a decentralized event store. Ceramic
+and OrbisDB share the same account model - Decentralized Identifiers, DID for short.
+
+DIDs have unique properties, they are self-verifiable which allows users to own their data without
+relying on 3rd parties for verification. No matter which app you use in our ecosystem, you can bring
+your identity with you - it's yours.
+
+You can recognize DIDs by their simple format
+
+```bash
+did:<method>:<data>
+```
+
+## DIDs in OrbisDB
+
+DIDs are one of the foundational concepts at OrbisDB. They allow users to fully own their identity,
+as well as their data. Each OrbisDB session is based on a DID. Every OrbisDB row entry is signed and
+owned by the original author's DID. You can verify this by checking the `controller` field.
+
+However, you don't _need_ to understand everything about DIDs or how they work. We made sure to
+simplify the process and abstract all the complexities using our SDK and UI.
+
+### Code example (EVM)
+
+With OrbisDB, everything DID-related is handled by a single method - `connectUser`. Learn how to
+[initialize OrbisDB](/docs/orbisdb/sdk-reference) and
+[authenticate users](/docs/orbisdb/sdk-reference/auth).
+
+```tsx
+import { OrbisDB } from "@useorbis/db-sdk";
+import { OrbisEVMAuth } from "@useorbis/db-sdk/auth";
+
+// Browser provider (ie. Metamask)
+const provider = window.ethereum;
+
+// Orbis Authenticator
+const auth = new OrbisEVMAuth(provider);
+
+// Authenticate the user and persist the session in localStorage
+const authResult: OrbisConnectResult = await orbis.connectUser({ auth });
+
+// Log the result
+console.log({ authResult });
+```
+
+## DID types
+
+DIDs have multiple methods by which they can be created. The ones used by Ceramic and OrbisDB are
+`did:pkh` and `did:key`.
+
+### did:pkh
+
+`did:pkh` is the most commonly used method because it's simple to derive. It's based on the public
+key of the end user, so it's native to all the web3 EOA wallets. The DID is derived from an end
+user's personal signature, allowing users to authorize apps for specific operations. This helps with
+the UX as users need to sign once for the duration of the session (3 months is the OrbisDB default).
+
+#### Format
+
+```bash
+did:pkh:<network>:<chain>:<address>
+```
+
+#### When to use `did:pkh`
+
+`did:pkh` is a web3 wallet friendly format as it relies on the already-existing private/public key
+pair. It's used by the OrbisDB Dashboard and we recommend it as the default format for your
+applications. It allows users to use their existing wallets without the need of remembering or
+saving another seed.
+
+> `did:pkh` format can be used with EOA wallets only, **Smart Contract wallets are not supported**
+> as they do not have a private key.
+
+#### Example - Ethereum (EVM)
+
+An example of a `did:pkh` for an EVM wallet is
+
+```bash
+did:pkh:eip155:1:0x0c63b64022edf1860a3ee5137c2bacb31aff1379
+```
+
+If you're interested in the full specification, check out the
+[did:pkh draft](https://github.com/w3c-ccg/did-pkh/blob/main/did-pkh-method-draft.md).
+
+### did:key
+
+`did:key` method is based on a randomly generated key pair. Unlike `did:pkh`, it's not derived from
+a signature or an existing key pair. Instead, a new key pair is generated using `Ed25519` and the
+value needs to be securely stored by the end user.
+
+#### Format
+
+```bash
+did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
+```
+
+#### When to use `did:key`
+
+`did:key` is best used when an EOA wallet is not available or isn't pre-existing. We often use it on
+the server-side, as storing a new seed is just another secret. Using `did:key` for your end users is
+not recommended as they need to store a new seed and if they were to lose it - they'd lose all
+access to their data.
+
+#### Example - Ed25519
+
+```bash
+did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
+```
+
+The above example comes from the official
+[did:key method specification](https://w3c-ccg.github.io/did-method-key/#format).