Sphere MediaLet’s talk Arcana Social
Sphere original · Software in developmentArcana's interface sits over a larger engineering system: cloud hosting, encrypted messaging, realtime voice and shared tools all depend on the same identity, device and permission boundaries.
The implementation combines a shared client, a modular backend and explicit security contracts. The result is one platform for private communication and collaborative work, not a collection of disconnected features.
01 / Client shell The React and TypeScript interface composes messaging, community and planning state over shared domain and policy contracts.
The engineering problem
A social platform can look unified while hiding very different requirements for authority, persistence, encryption and realtime delivery. Arcana's architecture makes those differences explicit instead of forcing every feature through one generic subsystem.
Application services, data, media and operations have different reliability and access requirements. The hosting model keeps those concerns separated without exposing infrastructure decisions through the product surface.
A private message, attachment, voice call and shared Workspace object do not have the same readability requirements. Encryption, permissions and collaboration behaviour are designed for the context instead of reduced to one blanket claim.
Call admission, room membership, device trust and revocation remain authorized even when media travels through dedicated realtime infrastructure. Reconnect and access changes need predictable failure behaviour.
Boards, pages, saved collections, filters, variables and editors all need collaboration, permissions and history. They reuse a Workspace substrate instead of inventing isolated identity, storage and access systems.
The system architecture
Arcana uses a modular platform model: identity, messaging, policy and audit stay shared while collaborative capabilities retain clear ownership and access boundaries.
A deliberately simplified public view of the system's major responsibilities.
Responsive interface · Local media controls
Identity · Messaging · Communities · Policy · Audit
Pages · Boards · Filters · Variables · Editors
Application · Data · Media · Operations
Technical pillars
Arcana uses an AWS-based hosting environment with separated application, data, media and operational concerns. The case study intentionally keeps the deployment topology and operating procedures private.
Private messaging is designed around client-side encryption and device-aware access. Transport security, stored-data protection and E2EE remain distinct boundaries rather than interchangeable marketing labels.
Call permissions and room state are separated from dedicated media routing. That keeps realtime communication responsive while preserving a clear trust boundary around private media.
Workspace and channel search narrow results through the same access rules as the underlying content. Filters and saved views improve retrieval without becoming a separate source of authority.
Pages, boards, planning, publishing, saved collections, permissions and activity reuse one Workspace substrate. Specialized surfaces consume shared contracts instead of building parallel collaboration silos.
Shared feature contracts, interface patterns and typed data models let Arcana add collaborative tools without creating a new identity, permission and activity system for each one.
A protected request path
A private action moves through a small set of protected layers. Each layer owns one responsibility while implementation-specific services and internal controls remain outside this public view.
Validate the action and prepare private content before it crosses the application boundary.
Reconfirm the account, device, membership and feature permissions for the request.
Keep messaging and security behaviour inside owned platform contracts.
Persist protected content, notify authorized recipients and record safe operational signals.
Security architecture
Arcana separates encrypted transport, managed at-rest protection and content-level end-to-end encryption. Private messages and encrypted attachments use a client-side protection boundary; shared and moderated surfaces remain readable where their functions require it.
Device trust is treated separately from account login so access to an account does not automatically imply access to every encrypted history. The public case study intentionally omits key formats, migration mechanics and internal recovery procedures.
Private-message and attachment content is protected before storage or delivery, with access scoped to approved devices.
Current product boundaryWorkspace, community and moderation tools use explicit access policy when collaboration requires server-readable information.
No blanket E2EE claimVoice architecture
Arcana separates call authority from media transport. The platform can decide who may join and which device is active while dedicated realtime infrastructure handles the media path.
Session, membership, device trust, room state and access changes are checked by the platform.
Policy boundaryPurpose-built media services handle low-latency audio without taking over application permissions.
Separate media boundaryMute, device preferences and optional voice effects remain close to the participant experience.
Privacy-aware defaultsMembership, trust and room-state changes are reflected before protected participation continues.
Optional spatial and effect processing stays client-local, with a normal-audio fallback.
Unavailable privacy or authority requirements close the protected path instead of silently weakening it.
Architecture shown at a deliberately high level · Provider topology and security mechanics remain private
The technical result
The architecture keeps Arcana deployable as one application while giving cloud services, crypto, calls and collaborative tools explicit boundaries. New capabilities reuse identity, permissions, audit and interface composition without reaching directly across every domain.
Application engineering
Sphere designs the product surface and the systems behind it: domain architecture, security boundaries, realtime behaviour, infrastructure adapters and cross-platform delivery.
Talk to us about your application