Architecture overview
Four layers — community apps, the operator's deployment, Symorva foundation modules and shared services — with the request flows and boundaries between them.
Symorva separates what a community owns from what it shares. The community's apps, accounts, messages and records belong to the operator and run in the operator's environment. Shared services handle workloads that benefit from scale — real-time media, AI inference, metering — and receive only what each request needs.
The diagram shows the module design. Chat end-to-end encryption and TEE key protection for wallets are in developer preview; see Status & roadmap for what runs today in the reference deployment.
The four layers
1. Community apps
Native clients for iOS, Android (APK), macOS and Windows. Each build carries the operator's identity — name, icon, colours, theme, locales — and the navigation of its enabled modules, all generated from the manifest. Platform UI stays native: SwiftUI on Apple platforms and Jetpack Compose on Android, over a shared headless core that owns product state and rules. See Multi-platform delivery.
2. The operator's deployment
Everything that stores community data. It always contains:
| Component | Responsibility |
|---|---|
| Community server | Accounts, identity, community structure, roles and module host |
| Admin console | Operator console for members, content, modules and settings |
| Data stores | Relational database, cache, object storage and message queue |
Each enabled module adds its own service: the messaging service (chat), meeting service (meetings), studio service (AI studio), wallet service (wallet), directory service (DApps) and rewards service (creator economy). See Community deployment.
3. Symorva foundation modules
The reusable module implementations, wire contracts and composition rules that Symorva maintains and versions. Layer 3 is what Symorva ships; layer 2 is where it runs. The SDK's module catalog is the single source of truth for module metadata — the validator, the planner, the CLI and these docs all read from it.
4. Shared services
| Service | What it provides | Metered in |
|---|---|---|
| Real-time media | Low-latency audio and video for rooms, plus a low-latency streaming edge for large audiences | participant-minutes, broadcast-viewer-minutes |
| AI inference & generation | Model gateway for chat, image and video generation with per-community quotas | ai-tokens, images, video-seconds |
| Resource metering & settlement | Usage records for shared services and settlement of creator revenue | settled-payouts |
See Shared services.
Request and data flows
Sending a message
- The sender's app encrypts the message content on the device when
modules.chat.e2eeis on. - The app submits the message to the messaging service in the operator's deployment. The service applies membership and policy checks — for example mutes and bans — before delivery.
- The messaging service routes and stores the message and pushes it to recipients' devices, where authorised devices decrypt it.
No shared service is involved. Chat has no metered units.
Joining a meeting
- The app asks the meeting service to join a room.
- The meeting service checks the member's permission and returns a short-lived, room-scoped media credential.
- The app connects to the shared real-time media service with that credential. In large-room mode, speakers stay on real-time media and listeners receive a signed playback address on the streaming edge.
- The media service records participant-minutes and viewer-minutes against the community.
The media service never receives the member directory or chat history — only the credential and the media.
Using the AI studio
- The member starts a request in the app — a prompt, an image to generate, a project step.
- The studio service in the operator's deployment checks permissions, publishing rules and quota, and forwards the request to the shared AI service.
- The AI service runs inference and returns the result; the studio service stores the project and generated assets in the operator's data stores.
Chat content is never sent unless the member has granted the assistant access to a conversation from their own device. See AI & creator studio.
Moving value
- The member prepares a transfer or payment in the app and confirms it.
- The wallet service in the operator's deployment validates the request against its rules and records it.
- Signing runs in a protected key boundary, never in the business API. In the module design that boundary is a trusted execution environment.
Wallet operations do not touch shared services. Creator payouts settle through the community's wallet service; the metering service records them.
What crosses each boundary
| Boundary | Crosses | Does not cross |
|---|---|---|
| App → operator deployment | Authenticated API calls, message envelopes (ciphertext when E2EE is on), media uploads, confirmed payment commands | Device private keys; plaintext of encrypted messages |
| Operator deployment → real-time media | Room-scoped short-lived credentials, media streams encrypted in transit | Member directory, chat history, wallet data |
| Operator deployment → AI service | The inputs a member or operator submits for a request, community identifier, quota context | Chat content without an explicit member grant; contact lists |
| Shared services → metering | Usage records: community, module, unit, quantity, time window | Content of any kind |
| Symorva → operator deployment | Versioned module releases and schema migrations | — |
| Operator deployment → Symorva | Usage records for shared services only | Member data, message data, wallet data |
Design principles
These principles come from the reference deployment and carry over unchanged:
- Separate failure domains. The messaging core and the business services are deployed and upgraded independently and communicate over a stable internal network, so one can be rolled back without the other.
- Configuration outside the code. Deployments track example configuration contracts; real secrets, certificates and signing material live only in the operator's secret store.
- Clients are build artifacts. Apps are produced per environment from central configuration; they are not long-running services.
- Explicit schema ownership. A new database is initialised once from a published baseline; after that, only managed, versioned migrations change it, and they run before a service starts.
- Native UI, shared rules. Platform agreement is tested at product interfaces and reference states, not forced through a shared renderer.
- A brand may change presentation, not invariants. The manifest can change identity, presentation, copy and enabled modules. It cannot change the business rules of conversations, messages, relationships or communities.