Core concepts
The vocabulary used across Symorva — who runs what, what a manifest describes, and how modules, deployments and shared services relate.
Symorva uses a small set of terms consistently across the manifest, the SDK, the CLI and these docs. Each term below maps to something concrete in symorva.config.json or in the deployment plan the SDK produces.
Operator
The organisation that owns and runs a community product: a community, DAO, creator, independent team or one-person company (OPC). The operator owns the deployment, its data stores, its domain and its app signing identities, and is responsible for the rules members agree to. Operators work in the admin console, which is part of every deployment.
Community
One community product with one identity. In the manifest it is the community block: a stable id (a lowercase slug such as orbit-collective), a display name of up to 28 characters, an optional description, the locales it ships in, and optionally the template it started from. One manifest describes exactly one community.
Member
A person with an account in a community. Members are scoped to the community's own deployment — accounts, profiles, roles and relationships live in the operator's data stores, not in a shared Symorva directory. A member's role inside chat (owner, admin, moderator, member, guest) is configured per community; see Chat.
Module
A unit of capability with a fixed contract: what it offers members, the server-side component it deploys into the operator's environment, the shared services it consumes, the units it is metered in and the privacy scope it guarantees.
There are six modules. Two are foundation modules and are always enabled; four are optional.
| Module | Manifest key | Kind | Requires |
|---|---|---|---|
| Chat & communities | chat | foundation | — |
| Meetings & live rooms | meetings | foundation | chat |
| AI & creator studio | aiStudio | optional | chat |
| Wallets & assets | wallet | optional | chat |
| DApps & ecosystem | dapps | optional | chat |
| Creator economy | creatorEconomy | optional | wallet |
See Modules for the catalog and composition rules.
Manifest
The single source of truth for a community, stored as symorva.config.json. It declares identity, brand, modules, platforms, deployment and shared-service connections. Defaults may be omitted; the SDK applies them during validation. The same manifest drives the server deployment and every platform build. Schema version 1 is current. See the Manifest reference.
{
"schemaVersion": 1,
"community": { "id": "orbit", "name": "Orbit" },
"brand": { "primaryColor": "#6E5BFF" },
"modules": {},
"platforms": ["ios", "android-apk"],
"deployment": { "region": "eu-central" }
}This manifest is valid. With defaults applied it enables chat and meetings, ships iOS and Android builds, and deploys in self-hosted mode.
Template
A starting manifest for a common kind of community: dao, creator, team or ecosystem. A template only pre-fills the manifest; after symorva init the file is yours, and community.template is kept as a label.
Diagnostic
A finding produced by validation. Each diagnostic has a level (error, warning or info), a stable machine-readable code such as module.requires, the JSON path of the field it concerns, and a human-readable message. A manifest with any error is invalid; warnings and info notes do not block planning.
Deployment
The set of components that run in, and belong to, the operator's environment. Every deployment contains three core components — the community server, the admin console and the operator's data stores — plus one service per enabled module. deployment.mode is either self-hosted (the operator runs the infrastructure) or managed (the Symorva team runs it on the operator's behalf). See Community deployment.
Deployment plan
The resolved view of a manifest, produced by symorva plan or planDeployment(): the enabled modules, the owned components, the shared services in use with the modules that use them and their metered units, the client build targets, the app navigation and the privacy protection of each module. The plan is deterministic — the same manifest always yields the same plan.
Shared service
A Symorva service that communities connect to rather than run themselves:
| Service | Manifest key | Used by |
|---|---|---|
| Real-time media | sharedServices.media | Meetings |
| AI inference & generation | sharedServices.ai | AI & creator studio |
| Resource metering & settlement | sharedServices.metering | Every metered service; creator economy settlement |
Shared services receive only what a request needs — a room-scoped media credential, a generation request, a usage record — never the community's member directory or message history. See Shared services.
Platform target
A client the community ships to. The platforms array accepts ios, android-apk, macos and windows. Each target produces a signed artifact under the operator's identity. The experience is mobile-first; desktop targets share the same configuration. See Multi-platform delivery.
Metered unit
A unit of shared-service usage recorded against a community: participant-minutes and broadcast-viewer-minutes (meetings), ai-tokens, images and video-seconds (AI studio), and settled-payouts (creator economy). Modules that run entirely inside the operator's deployment — chat, wallet and DApps — have no metered units. See Metering & settlement.
Reference deployment
The live consumer IM application whose stack Symorva generalises. A capability marked Available runs there today.