Data ownership & boundaries
Where each category of community data lives, who can read it, and what each privacy protection does and does not cover.
The operator owns the community's data. It lives in the operator's data stores, in the operator's environment, under the operator's domain. Symorva's shared services process individual requests and keep usage records; they do not hold a copy of the community.
This page lists each category of data, where it lives and who can read it, followed by the limits of each protection. Protections marked as module design are in developer preview; see Status & roadmap.
Data map
| Data | Where it lives | Who can read it |
|---|---|---|
| Accounts, profiles, sessions, devices | Operator's relational database | The member; operator staff through the admin console, subject to console roles |
| Community structure, groups, roles | Operator's relational database and messaging-core stores | Members according to their role; operator staff |
| Message content | Messaging-core stores in the operator's deployment | With chat.e2ee on: only authorised recipient devices (module design). With it off: also the community server |
| Message metadata — sender, recipients, conversation, timestamps, size, group membership | Messaging-core stores | The community server and operator staff. Metadata is not covered by end-to-end encryption |
| Attachments — images, video, files, voice | Operator's object storage | Same scope as the message that references them |
| Meeting media | Transits the shared real-time media service; not stored by default | Room participants. Encrypted in transit, not end to end |
| Meeting recordings | Operator's object storage, when meetings.recording is on | Members the room's policy allows; operator staff |
| AI projects, prompts, generated assets | Operator's data stores; inputs transit the shared AI service per request | The member and, for published assets, the audience the publishing rules allow |
| Conversation content shared with the assistant | Sent from the member's device for the granted scope only | The AI service, for the duration of the request |
| Wallet balances, transfers, payment records | Operator's wallet service and ledger | The member; operator staff with finance roles |
| Wallet key material | Protected key boundary of the wallet service | No business API or operator console. See key protection |
| DApp listings and settings | Operator's directory service | Public to members |
| Data shared with partner apps | Released per request from the member's app | The partner, only after the member approves the request (module design) |
| Usage records | Operator's deployment and Symorva metering | The operator and Symorva |
| Operator audit logs | Operator's relational database | Operator staff with audit roles |
What each protection covers
End-to-end encrypted chat
Message content is encrypted on the sender's device and decrypted only on authorised recipient devices. The community server stores and routes ciphertext. This is the chat module's design and is in developer preview; the reference deployment's messaging runs without end-to-end encryption today.
It does not cover:
- Metadata. Who talked to whom, when, in which group, and message sizes are visible to the community server.
- Other modules. It does not make meetings, AI inference, wallet operations or partner apps end-to-end encrypted.
- Content a member chooses to share. Forwarding a message, reporting it to moderators or granting the assistant access sends readable content to the chosen destination.
- Operator announcements. System messages sent through the Server API originate on the server and are not end-to-end encrypted; apps label them as system messages.
- Device compromise and screenshots. Content is readable on any authorised device.
When encryption is on, server-side content filters cannot inspect message bodies. Moderation then relies on member reports, which carry the reported content from the reporter's device, and on metadata-level controls such as mutes, bans and join approval.
TEE-integrated wallets
Sensitive key operations run inside a trusted execution environment, so the wallet service's business logic and the operator's staff never handle raw key material. This is the wallet module's design and is in developer preview; the reference deployment protects keys today with a separately deployed custody service. Exact key handling depends on the wallet implementation a community deploys.
It does not mean on-chain transactions are anonymous, that assets are held under any particular custody model, or that funds are insured.
AI access to conversations
The assistant never reads chat content by default. With aiStudio.chatContentAccess set to member-grant, a member can grant access to a conversation from their own device, and can revoke it. Operators cannot grant access on a member's behalf. With none, the assistant cannot be given conversation access at all.
Meetings
Room access is authorised by the community server; media is encrypted in transit between devices and the media service. Meetings are not end-to-end encrypted.
Partner apps
Partner apps in the DApp directory receive no member data unless the member approves each request. Opening an external destination shows a risk confirmation first.
Backups
Operator backups contain whatever the operator's stores contain: ciphertext for encrypted messages, plaintext for everything else. Backup encryption at rest, retention and location are set by the operator's infrastructure. Device-side backups of decrypted messages are a separate scope, governed by the member's device settings and documented with the encryption profile when it reaches general availability.
Portability
Because the data stores belong to the operator, the operator can export, migrate or delete community data with its own tools. Disconnecting a shared service — for example setting sharedServices.ai to none — removes that service from the deployment plan without moving data.
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.
Multi-platform delivery
One manifest, four platform targets — what is generated for each build, what stays native, and how the experience is kept consistent.