Shared services
Real-time media, AI inference and generation, and resource metering — what each shared service does, what it receives, how it is isolated per community and how it is configured.
Shared services are the part of Symorva that communities connect to instead of running themselves. They exist for workloads where scale matters: a global media plane, a model gateway, and a usage ledger. Each one is multi-tenant by community, receives only what a request needs, and records usage against the community that made the request.
| Service | Manifest key | Values | Used by | Status |
|---|---|---|---|---|
| Real-time media | sharedServices.media | symorva (default) or none | Meetings | Available for rooms and calls; streaming edge in preview |
| AI inference & generation | sharedServices.ai | symorva (default) or none | AI & creator studio | Preview |
| Resource metering & settlement | sharedServices.metering | symorva only | All metered services, creator economy | Preview |
The planner adds a shared service to a deployment plan only when an enabled module uses it. Metering is added whenever any other shared service is present, because it records every shared-service unit.
Real-time media
Available· Runs today in the reference deploymentThe real-time media service carries audio, video and screen sharing for meetings and calls. The reference deployment runs its multi-party meetings, group calls and one-to-one calls on a real-time media plane today, with the meeting service in the operator's deployment controlling room lifecycle and permissions.
How a session is authorised. The member's app never authenticates to the media service directly. The operator's meeting service checks the member's right to join and issues a short-lived credential scoped to one room and one publishing role. The media service accepts that credential and nothing else. A member admitted as a listener receives no publishing credential.
Large rooms. When a broadcast room's audience exceeds 500, the room runs in large-room mode: the stage — hosts, co-moderators and speakers — stays on real-time media, while listeners receive the stage mix from a low-latency streaming edge through a signed playback address. The mode is fixed when the room opens. Large-room mode and the streaming edge are in developer preview: they have been built and exercised end to end in an isolated environment and are not yet part of the reference deployment.
What it receives. Room-scoped credentials and media streams, encrypted in transit. It does not receive member profiles, the community's member directory or chat history. Meeting media is not end-to-end encrypted.
Metered in. participant-minutes for connected participants and broadcast-viewer-minutes for listeners on the streaming edge.
Configuration. Meetings are a foundation module, so the media service is required. sharedServices.media: "none" is accepted by the schema but currently fails validation with service.media-required.
AI inference & generation
Developer preview· Interface published, subject to changeThe AI service is a model gateway for chat, image and video generation with per-community quotas. Requests come from the studio service in the operator's deployment, never directly from member devices. The reference stack includes an AI control plane that routes model traffic through a gateway with quota enforcement, and an AI creation pipeline whose paid commands are quoted, admitted and settled idempotently; the member-facing studio is not yet generally available there.
What it receives. The inputs a member or operator submits for a request — a prompt, reference images, a script — and the community identifier and quota context. It does not receive chat content unless a member has granted the assistant access to a specific conversation from their own device. See Chat content access.
What it does not imply. Chat encryption does not make AI inference encrypted end to end. Content a member chooses to send to the assistant is processed by the AI service in plaintext.
Metered in. ai-tokens, images, video-seconds.
Configuration. Set sharedServices.ai to none to disconnect it. Validation then requires modules.aiStudio.enabled to be false; otherwise it reports service.ai-required.
Resource metering & settlement
Developer preview· Interface published, subject to changeThe metering service receives usage records from the other shared services and from the creator economy's rewards service, aggregates them per community and produces statements. It also records creator payouts, which settle through the community's own wallet service — Symorva records the settlement, the community's wallet moves the value.
What it receives. Usage records only: community, module, unit, quantity and time window. No content.
Metered in. settled-payouts (creator economy). It records the units of every other shared service.
Configuration. sharedServices.metering accepts only symorva. See Metering & settlement.
Isolation between communities
- Identity. Every request to a shared service is made on behalf of one community, by that community's deployment, with credentials issued to that deployment.
- Quotas. Quotas and rate limits are per community; one community's usage cannot exhaust another's.
- Data. Shared services keep no per-member profile. Generated assets and recordings are returned to, and stored by, the community's own deployment.
- Records. Usage records are keyed by community and module, so statements can be reconciled line by line.
Running without shared services
A community can run without the AI service by disabling the AI studio. The media service is required while meetings remain a foundation module. Metering is always connected, because it is how shared-service usage is accounted for.