Introduction
Symorva is modular social infrastructure for communities that want their own branded app, deployed under their own control and connected to shared services.
Symorva gives a community its own product. An operator — a community, DAO, creator, independent team or one-person company — describes the app it wants in a single manifest: its name and brand, the modules it uses, the platforms it ships to and where it runs. Symorva turns that manifest into a deployment the operator owns and native apps its members install.
The community app is composed from modules. Chat and meetings form the foundation and are always present. AI and creator tools, wallets, a DApp directory and a creator economy are added as needed. Everything that holds community data runs in the operator's environment. Capabilities that are expensive or impractical to run per community — real-time media, AI inference, usage metering — are provided as shared Symorva services and metered per community.
Who it is for
| Operator | Typical composition |
|---|---|
| DAO or collective | Encrypted chat with roles and join approvals, governance calls, wallet-based member services |
| Web3 or DApp ecosystem | Member support, AMAs in broadcast rooms, a curated DApp directory, wallets |
| Creators and AI studios | AI studio for short dramas and product ads, broadcast rooms, tips and remix revenue sharing |
| Independent team or OPC | Private chat and meetings with collaborators and clients, AI assistance |
Each of these is available as a starting template in the CLI. See Quickstart.
How the pieces fit
Symorva is organised in four layers. Each layer has a clear owner and a documented boundary.
- Community apps. Native clients for iOS, Android (APK), macOS and Windows, built from the operator's manifest and carrying the operator's brand.
- The operator's deployment. The community server, admin console, module services and data stores. It runs in, and belongs to, the operator's environment.
- Symorva foundation modules. The reusable module code, contracts and composition rules that Symorva maintains and the operator's deployment runs.
- Shared services. Real-time media, AI inference and generation, and resource metering and settlement, connected as configured and metered per community.
The architecture overview describes each layer, the request and data flows between them, and exactly what crosses each boundary.
Grounded in a live deployment
Symorva generalises a stack that runs today in a live consumer IM application, referred to throughout these docs as the reference deployment: a self-hosted messaging core, a business API and an admin API, native SwiftUI and Jetpack Compose clients, a real-time media plane for calls and meetings, a wallet service with an isolated custody boundary, and managed database migrations. Where a capability already runs there, these docs say so. Where it is new to Symorva, they say that too.
Every module, SDK and API page carries a status badge:
- Available· Runs today in the reference deployment
- Developer preview· Interface published, subject to change
- Planned· On the roadmap
Available means the capability runs today in the reference deployment. Developer preview means the interface is designed and published in these docs and may change before general availability. Planned means it is on the roadmap with no interface commitment yet.
The full matrix is on Status & roadmap.
The SDK is in developer preview and is distributed to design partners by the Symorva team. It is not published to a public package registry. Contact the team for access.
What is in these docs
Core concepts
Operator, community, member, module, manifest, deployment, shared service and platform target.
Quickstart
Create, validate and plan a community manifest with the CLI in a few minutes.
Architecture
The four layers, request flows, and what crosses each boundary.
Modules
Capabilities, configuration, events, privacy scope and metered units for each module.
Manifest reference
Every field of symorva.config.json, with types, defaults, ranges and diagnostics.
Security & privacy
Trust boundaries, encryption scope, key protection and operator controls.