Contexts

Overview

Content on Orbis is available across the protocol and is stored on an open data network - Ceramic.
We believe users should still have the ability to create their own spaces in this massive protocol.
These spaces come in the form of Contexts.

Contexts allow users to organize content in the way it makes sense for them, as well as define Access Gating rules to choose who can contribute.

Contexts can be used to organize Posts, Conversations and even other Contexts.

Access Gating

By defining Access Gating rules, users can choose who can contribute (write) to their spaces.
These rules are handled by Orbis Nodes at an indexing layer.

Contexts can be Token & Metadata Gated, gated based on Credentials or a set of DIDs.
These rules can also be combined.

Find out more about Access Gating and other forms of Access Control here.

Dynamic Contexts

Sometimes we may have a rule which applies to many different content pieces (ie. blog articles).
In order to add content relevant to the content piece we can use Dynamic Contexts.

Dynamic Contexts allow you to append a unique suffix to Context's (stream) ID.
Orbis Nodes will intelligently use Access Gating rules of the Context while organizing content based on the context ID and the provided suffix.

This allows you to share a context rule across many "dynamic spaces", without having to create a separate context for each content piece.
Dynamic Contexts greatly simplify content micro-organization.

The format is <CONTEXT_ID>:<SUFFIX>

Dynamic Context Example

Let's say we have a context with an ID kjzl6cwe1jw147eabkq3k4z6ka604w0xksr5k9ildy1glfe1ebkcfmtu8k2d94j to which only active holders of our NFT can contribute.

We decide to build a Wordpress-hosted blog to share updates with our community, but we want to enable Orbis Posts to serve as comments.
We can use Orbis Discussion Feed Component with a Dynamic Context to achieve this.

Since each article will have a unique ID, we can use it as a suffix.

This means our final Dynamic Context format will be
kjzl6cwe1jw147eabkq3k4z6ka604w0xksr5k9ildy1glfe1ebkcfmtu8k2d94j:<ARTICLE_ID>.

This is a pseudo preview of what the component might look like for the article with an ID 7293671.

import { Discussion } from "@orbisclub/components";
import "@orbisclub/components/dist/index.modern.css";
 
<Discussion context="kjzl6cwe1jw147eabkq3k4z6ka604w0xksr5k9ildy1glfe1ebkcfmtu8k2d94j:7293671" />

Sub-contexts

As mentioned above, Contexts can be used to organize other Contexts.
This allows for advanced forms of organization as well as simplified Access Gating rules.

You're also able to query all Sub-contexts given a parent Context.

Sub-contexts can be thought of as categories, channels or groups of a given parent Context.
Each Sub-context can have its own set of Access Gating rules as well Sub-contexts of its own.

Sub-contexts Example

A good use case for Sub-contexts can be found in our open-source Forum template.
In this example, we used a parent Context to organize content across the Forum, with each Sub-context acting as a separate Category.

This demo can be seen live at forum.useorbis.com (opens in a new tab).
"Announcements", "General", "Components" and "SDK" are names of Sub-contexts (categories) to which a Post may belong to.

Use case

Contexts are an extremely versatile primitive. They allow any project to tailor the content structure to their needs.
They are used to organize and Access Gate content.

Some examples of how projects are using Contexts:

• token gated DAO governance and discussions
• channels for a social messaging app using Sub-contexts
• credential gated access to channels of a conference
• website / blog comments using Dynamic Contexts
• forum categories
• NFT project discussions integrated into a marketplace using Dynamic Contexts

Properties

Schema

The stream ID of Context schema is k3y52l7qbv1frxwheea6kvunklvn2z6fgzsdzaz18uger06l7svtd9yylf9ph883k.

You can check the latest version using Cerscan (opens in a new tab).

Format

{
	"name": "string", // required
    "displayName": "string",
    "context": "string",
    "project_id": "string",
    "websiteUrl": "string",
    "accessRules": [
        "Visit Access Gating & Rules section"
    ],
    "integrations": {
        "discord": {
            "channel_id": "string"
        }
    }
}

Parameter explanation:

• name - internal context name, it will be available to other Orbis-powered apps
• displayName - external name to be used by Orbis-powered apps for display purposes
• context - (stream) ID of the parent context
  • if set, this context will be a sub-context, meaning it can be queried and grouped based on the parent
• project_id - project this context is a part of
• websiteUrl - your app's or project website, can be used by Orbis-powered apps for display purposes
• accessRules - Access Gating rules used for this context
• integrations - 3rd party integrations, currently the only option is discord
  • discord - this integration will forward all new posts from this context to the specified channel
    • this integration requires "Orbis Notifications" bot (opens in a new tab) to be installed
    • channel_id - Discord channel ID (opens in a new tab) bot will send the messages to

SDK methods

Related concepts