🎊Concepts

A selection of core concepts to better understand the Solarplex protocol.

Identity

Solarplex provides each user with a unique identity by assigning a DID (Decentralized Identifier), an emerging W3C standard for secure identification. Users can link their existing real-world and online identities, such as blockchain wallet pubkeys (Solana, Ethereum) and OAuth Provider Handles (Google, Twitter), to authenticate and interact with the protocol. All user data is stored and keyed by DID, enabling easy data export or deletion. As DIDs are system-agnostic, they can be used across platforms that support them.

Entities

The core data unit in Solarplex is the Postbox, where every piece of content at all levels is stored. Forums, topics within forums, and posts within topics are all considered Postboxes. There are support for multiple entities. (WIP)

Actions

User actions on the protocol, such as upvotes or downvotes, are linked to one or more Entities and signed with the user's public key for authentication. Postboxes can only be modified by their creators. Moderators, as privileged users, can hide Postboxes based on moderation policies but cannot edit them.

App View

App Views are client code interfaces that interact with the Solarplex protocol via HTTP APIs, such as Solarplex.xyz web App View, mobile apps, or xNFTs.

API Server

Each Solarplex protocol instance includes an API server, providing an HTTP API on top of the protocol's Datastore.

Datastore

Solarplex employs a datastore to cache the current protocol state for quick App View retrieval. It supports two types of stores: Real-time store, used by HTTP APIs for the latest protocol state (currently supporting Google Cloud Datastore), and Permanent store, for backing up protocol state snapshots into an immutable datastore like Arweave.

Validator

Solarplex relies on a validator service to read data from the Solana blockchain and ingest it into the real-time and/or permanent stores.