# Aphrodite Domain — Architecture > System architecture for the Aphrodite live streaming and performance platform: > 17 applications, a 190-library tree (roughly 186 implemented, four scaffolds), > service topology, and cross-domain dependencies. Counts and the > implemented-vs-scaffold split are verified against `apps/aphrodite/*` and > `libs/aphrodite/*`; Aphrodite has no `services/aphrodite/` tier — runnable > services live under `apps/aphrodite/`. --- Aphrodite is the sensual live streaming and creator economy domain in the Oshun monorepo. It provides the complete infrastructure behind a platform where performers — live humans, AI-generated personas, stylised androids, humanoid alien characters, and partnered strip-club venues — broadcast live video to viewers, viewers interact in real time through chat and haptic devices, and both parties transact through a token economy. The domain is named after the Greek goddess of love and beauty, reflecting its mission to treat sensual performance as a legitimate art form that deserves professional tooling. **The content cap.** Aphrodite caps the level of eroticism platform-wide at music-video-grade sensuality (the Nicki Minaj / Cardi B / Megan Thee Stallion / Drake / Future reference standard). Twerking in a thong, lingerie posing, sensual choreography, pole and burlesque routines, stylised android and alien-humanoid sensual performance, and live in-venue strip-club broadcasts are all on-policy. Full nudity, exposed genitals, exposed nipples, explicit sexual acts, and hardcore content are rejected by moderation regardless of audience or paywall. The cap is structural — wired into `@aphrodite/core`'s `content-policy` module, into moderation thresholds, into consent activity catalogues, into venue-partnership contracts, and into recommendation re-rankers that promote dance and choreography over purely-static sensual content. The platform faces a distinctive architectural challenge: it must simultaneously handle the hard latency requirements of interactive live video (sub-3-second glass-to-glass for private shows), the compliance burden of an adult-adjacent platform (18 U.S.C. § 2257, GDPR, UK Online Safety Act, age verification, synthetic-content disclosure for AI / android / alien embodiments), and the safety responsibilities of a platform where performer wellbeing is a genuine concern. Each concern drives distinct architectural decisions — which is why Aphrodite's library tree is unusually large and why compliance is wired directly into service middleware rather than left to application code. At its core, Aphrodite is a set of 17 independent Hono microservices (the `apps/aphrodite/*` layer) backed by 190 libraries (`libs/aphrodite/*`) that implement everything from RTMP ingest to haptic device protocols to Jungian archetype-based persona development. The services share a PostgreSQL database, a Redis cache, a Kafka-backed event bus, and object storage (MinIO/S3), but each service owns its own concern independently enough to scale and deploy separately. --- ## Guiding Principles 1. **Real-time first** — The platform's core value is live interactive streaming. Architecture decisions prioritize low latency over simplicity. 2. **Compliance by design** — 18 U.S.C. 2257, GDPR, age verification, and content moderation are structural requirements, not bolt-ons. 3. **Performer sovereignty** — All device interactions, content policies, and viewer access controls are broadcaster-owned and broadcaster-initiated. 4. **Microservice topology** — Each major concern (streaming, chat, payment, devices, notifications) is an independent service with its own data store. 5. **Independent scalability** — Streaming infrastructure scales independently from payment processing, which scales independently from chat. --- ## System Overview The diagram below shows how clients connect through five independent service clusters to a shared data layer. Notice that all five service clusters connect directly to clients — there is no single API gateway. Each service handles its own authentication, rate limiting, and request validation independently. ``` ┌────────────────────────────────────────┐ │ CLIENTS │ │ Viewer Web Broadcaster Web Mobile │ │ VR App Desktop OBS Admin │ └──────────────────┬─────────────────────┘ │ ┌───────────────┬────────────────┼──────────────┬─────────────────┐ ▼ ▼ ▼ ▼ ▼ ┌──────────────┐ ┌────────────┐ ┌──────────────┐ ┌───────────┐ ┌────────────────┐ │ Streaming │ │ Chat │ │ Payment │ │ Devices │ │ Notifications │ │ Service │ │ Service │ │ Service │ │ Service │ │ Service │ └──────┬───────┘ └─────┬──────┘ └──────┬───────┘ └─────┬─────┘ └───────┬────────┘ │ │ │ │ │ └───────────────┴───────────────┴───────────────┴───────────────┘ │ ┌────────────────┴────────────────────┐ │ DATA LAYER │ │ PostgreSQL │ Redis │ S3/MinIO │ │ Shared event bus │ └─────────────────────────────────────┘ ``` --- ## Application Layer (17 Applications) All 17 apps live under `apps/aphrodite/` and are Hono services (the mobile apps are React Native clients). Each registers a `/health` route group. Ports are not hardcoded in the application source — services bind a port from their environment — so the table omits speculative port numbers. The streaming and broadcaster services handle the ingest and production side of the platform; viewer and chat services handle the consumption side. Payment, devices, notifications, analytics, and CDN are independent cross-cutting services. Admin apps support platform operations rather than end users. | Application (`apps/aphrodite/…`) | Type | Purpose | | -------------------------------- | ------------ | ----------------------------------------------------------------------------- | | `streaming` | Hono service | RTMP / WebRTC ingest, transcoding, HLS distribution, recording, discovery | | `viewer` | Hono service | Viewer-facing API: streams, chat, tips, following, devices, shows, history | | `broadcaster` | Hono service | Broadcaster-facing API: streams, profile, settings, analytics, devices, shows | | `payment` | Hono service | Payment processing, token economy, tips, subscriptions, payouts, webhooks | | `chat` | Hono service | Chat rooms, messages, moderation, direct messages | | `devices` | Hono service | Device control, patterns, triggers | | `auth` | Hono service | Authentication and two-factor flows | | `notifications` | Hono service | Notification delivery API | | `analytics` | Hono service | Event ingestion and dashboard analytics | | `realtime-analytics` | Worker | Real-time stream analytics pipeline | | `cdn` | Hono service | CDN origin management, segment upload | | `vr` | Hono service | WebXR capture and playback API | | `admin` | Hono service | Admin control panel API | | `admin-bi-dashboard` | Hono service | Business intelligence analytics API | | `analytics-dashboard` | Hono service | Broadcaster self-serve analytics API | | `mobile-broadcaster` | Mobile (RN) | React Native broadcaster client | | `mobile-viewer` | Mobile (RN) | React Native viewer client | --- ## Library Layer (190 Libraries) `libs/aphrodite/` contains 190 library directories. Roughly 186 have a substantial `src/` implementation. **Four are scaffolds** — `@aphrodite/chat`, `@aphrodite/payment`, `@aphrodite/safety`, and `@aphrodite/sdk` each export a real `types.ts` but their functional subdirectories contain only a version constant and an `implementation will be added during service migration` comment. The tables below highlight the infrastructure and subsystem libraries; the full grouped catalogue is in `specifications.md`. The library tree is deliberately wide rather than deep. Each functional area has its own dedicated libraries rather than sharing a monolithic helper package. This makes dependencies explicit, allows libraries to evolve at different speeds, and keeps test scope narrow. ### Infrastructure Libraries These six libraries are direct dependencies of almost every other Aphrodite library. They provide the data persistence, caching, storage, eventing, and test scaffolding that all domain logic depends on. | Library | Purpose | | ---------------------------- | ------------------------------------------------------------------ | | `@aphrodite/database` | Prisma schema, migrations, typed repository layer | | `@aphrodite/cache` | Redis cache with per-key TTL and invalidation helpers | | `@aphrodite/storage` | S3/MinIO file operations for VOD segments and thumbnails | | `@aphrodite/event-publisher` | Kafka event publication with retry and dead-letter handling | | `@aphrodite/testing` | Shared test utilities: mock streams, mock devices, fake tip events | ### Streaming Libraries The streaming libraries implement the full pipeline from ingest to delivery: RTMP ingest and validation at the source, real-time transcoding to multiple quality tiers, HLS packaging for delivery, and post-stream processing (recording, clipping, watermarking, upscaling). | Library | Purpose | | ------------------------------------ | ------------------------------------------------------------------------ | | `@aphrodite/streaming-core` | RTMP session management, stream key validation, transcoding job dispatch | | `@aphrodite/multi-source` | Multiple camera input management, source switching | | `@aphrodite/stream-upscaling` | AI-powered video upscaling (720p → 1080p/4K) | | `@aphrodite/stream-watermarking` | Invisible watermark embedding for piracy tracing | | `@aphrodite/stream-content-analysis` | AI-based content classification and policy enforcement | | `@aphrodite/cloud-recording` | Cloud recording session management, VOD creation | | `@aphrodite/highlight-clipping` | Automated highlight detection and clip creation | | `@aphrodite/thumbnail-generation` | Automatic thumbnail extraction from stream frames | | `@aphrodite/vod-chaptering` | Chapter markers and VOD table-of-contents generation | | `@aphrodite/spatial-audio` | Spatial audio encoding for VR streams | ### Device Integration Libraries Interactive device integration is one of Aphrodite's defining differentiators. These libraries implement the full stack from the physical hardware protocol (Buttplug.io) up through safety enforcement, signal aggregation, and smart home integration. | Library | Purpose | | ---------------------------------- | --------------------------------------------------------------------------------- | | `@aphrodite/buttplug` | Buttplug.io protocol client wrapper | | `@aphrodite/haptics` | Haptic event scheduling and pattern library | | `@aphrodite/bidirectional-haptics` | Two-way haptic session management (viewer-to-device) | | `@aphrodite/audio-haptics` | Audio level → haptic intensity conversion | | `@aphrodite/motion-haptics` | Motion velocity → haptic feedback translation | | `@aphrodite/device-protocols` | Protocol abstraction for non-Buttplug devices | | `@aphrodite/device-safety` | Intensity cap enforcement, safe-word kill switch | | `@aphrodite/smart-home` | Tip/event to smart home device (lights, ambiance) control | | `@aphrodite/sensation-bus` | Unified haptic event bus routing signals between input sources and output devices | | `@aphrodite/wearables` | Wearable sensor data ingestion | ### VR/AR Libraries The VR/AR libraries build a full immersive viewing stack from the WebXR session layer down through avatar rendering, physics, and eye tracking. Meta Quest is the primary VR target, with PC VR headsets also supported. | Library | Purpose | | ------------------------------------ | ---------------------------------------------------- | | `@aphrodite/vr-core` | WebXR session management, renderer configuration | | `@aphrodite/vr-haptics` | VR controller haptic feedback | | `@aphrodite/vr-quest` | Meta Quest-specific optimizations | | `@aphrodite/viewer-avatars` | Viewer avatar creation, customization, and rendering | | `@aphrodite/avatar-renderer` | Avatar mesh rendering pipeline | | `@aphrodite/avatar-motion` | Avatar motion capture and animation playback | | `@aphrodite/avatar-customization-ui` | Avatar customization UI components | | `@aphrodite/avatar-physics` | Cloth and body physics simulation | | `@aphrodite/ar-overlays` | AR overlay rendering layer for non-VR clients | | `@aphrodite/eye-tracking` | Eye tracking data processing for VR | | `@aphrodite/volumetric-capture` | Volumetric video capture and streaming | ### Chat Libraries Chat is more than a message feed in Aphrodite. It is a primary revenue driver: tip acknowledgment animations, goal progress bars, virtual gifts, and entertainment widgets all surface through the chat layer. | Library | Purpose | | -------------------------------- | ------------------------------------------------- | | `@aphrodite/chat-core` | WebSocket-based chat message delivery and history | | `@aphrodite/chat-moderation` | Automated filtering, ban enforcement, slow mode | | `@aphrodite/chat-entertainment` | Stickers, GIFs, emote pack management | | `@aphrodite/tip-acknowledgment` | On-screen tip display with customizable overlays | | `@aphrodite/tip-effects` | Animated effects triggered by tip events | | `@aphrodite/tip-goals` | Goal bars, progress tracking, completion actions | | `@aphrodite/virtual-gifts` | Animated virtual gift catalog and presentation | | `@aphrodite/viewer-interactions` | Interactable scene elements activated by viewers | | `@aphrodite/crowd-control` | Mass-participation interaction coordination | ### Payment and Monetization Libraries The payment libraries cover all money flows: fiat token purchases through adult-content-specialised processors (CCBill, Epoch, Segpay), cryptocurrency payments including privacy coins, per-minute private show billing, subscription management, and broadcaster payouts. | Library | Purpose | | ---------------------------- | ---------------------------------------------------------------------- | | `@aphrodite/payments` | CCBill, Epoch, Segpay, Stripe, and crypto payment gateway integrations | | `@aphrodite/crypto-payments` | Cryptocurrency payment processing | | `@aphrodite/privacy-coins` | Privacy coin payment (Monero, Zcash) support | | `@aphrodite/revenue-sharing` | Platform fee calculation and broadcaster payout computation | | `@aphrodite/ppv` | Pay-per-view unlock management | | `@aphrodite/nft-integration` | NFT-gated content access via `@aje/nft` | ### Compliance and Safety Libraries Adult-adjacent platforms face complex legal obligations even when capped at music-video-grade content. The compliance libraries treat regulation as a first-class concern: 18 U.S.C. § 2257 record-keeping, GDPR data subject rights, age verification, synthetic-content disclosure for AI / android / alien embodiments, and consent tracking are all implemented as dedicated libraries that are structurally coupled to service middleware rather than optional add-ons. The music-video cap itself is enforced by `@aphrodite/core`'s `content-policy` module (referenced by moderation, content tagging, partnership contracts, and recommendation re-rankers) and by the `over_cap_*` flags surfaced through `@aphrodite/stream-content-analysis`. | Library | Purpose | | ---------------------------------- | --------------------------------------------------------------- | | `@aphrodite/compliance-2257` | 18 U.S.C. 2257 record management and verification | | `@aphrodite/age-verification` | Age-gate workflows; Yoti, Veriff, and Stripe Identity providers | | `@aphrodite/gdpr-compliance` | GDPR workflows: data access, deletion, consent logging | | `@aphrodite/content-takedown` | DMCA and regulatory takedown processing | | `@aphrodite/drm` | Widevine/FairPlay DRM for protected VOD | | `@aphrodite/recording-prevention` | Client-side recording prevention controls | | `@aphrodite/e2e-encryption` | End-to-end encryption for private messages | | `@aphrodite/consent-engine` | Performer consent tracking per activity type | | `@aphrodite/performer-autonomy` | Broadcaster controls for viewer access and interaction limits | | `@aphrodite/performer-sovereignty` | Full performer control dashboard logic | | `@aphrodite/safety` | Scaffold — safety/CSAM/moderation types only; behaviour pending | | `@aphrodite/safety-intelligence` | AI-powered risk detection for vulnerable performers | | `@aphrodite/ethics` | Ethical interaction framework enforcement | | `@aphrodite/legal` | Legal record audit log and tamper-evident storage | | `@aphrodite/regulatory` | Jurisdiction-specific regulatory compliance | --- ## Communication Architecture Aphrodite uses three distinct communication patterns, each chosen to match the latency and consistency requirements of the data it carries. ### Real-Time Communication Client-facing real-time events flow over WebSocket connections, using the canonical event names defined in `@aphrodite/core`'s `WS_EVENTS` map. The naming convention uses a `domain:action` form — for example, `chat:message`, `stream:start`, or `device:command`. This allows clients to subscribe to specific event types without receiving unrelated traffic. - **Chat**: Real-time chat between viewers and the `chat` service, modelled in `@aphrodite/core`'s `WS_EVENTS` map (`chat:message`, `chat:delete`, etc.). - **Device control**: Device commands flow to the broadcaster's client and a local Buttplug.io server via `@aphrodite/buttplug`. - **Stream viewer events**: Viewer count, tip receipt, and goal progress are surfaced through the `stream:*`, `tip:*`, and `goal:*` WebSocket events. ### Inter-Service Communication Service-to-service communication uses two patterns depending on whether the call is synchronous or stateful. Synchronous lookups (e.g., the viewer service checking a broadcaster's profile) use HTTP. State-changing events that multiple services need to react to (e.g., a tip triggering both a device command and a goal update) flow through the shared event bus as typed, schema-validated messages. - **Shared event bus** (`@oshun/event-bus`, `@aphrodite/event-publisher`) for stateful cross-service events — the 22 `aphrodite.*` topics defined in `@oshun/contracts` (stream started, tip received, subscription changed, etc.). - **REST/HTTP** (Hono) for synchronous queries between services. - **Redis** (`@aphrodite/cache`) for shared real-time state (viewer counts, live tip totals, device status). --- ## Database Architecture All persistent Aphrodite state lives in a single PostgreSQL database named `aphrodite`, accessed through the Prisma schema at `libs/aphrodite/database/prisma/schema.prisma` (connection string: `APHRODITE_DATABASE_URL`). The schema defines 20 tables. `Broadcaster` and `Viewer` carry a `userId` referencing a platform user managed outside this schema — there is no `users` table in the Aphrodite schema. User identity is owned by the platform authentication layer; Aphrodite only stores domain-specific profile and activity data. Compliance, age-verification, and consent state are not stored as tables in this schema. They are modelled in their respective libraries (`@aphrodite/compliance-2257`, `@aphrodite/age-verification`, `@aphrodite/consent-engine`) to keep sensitive regulatory data isolated from general platform data and to allow each compliance library to evolve its storage model independently. ``` aphrodite (PostgreSQL database — schema.prisma) ├── broadcasters ├── viewers ├── streams ├── private_shows ├── private_show_requests ├── private_show_participants ├── stream_schedules ├── stream_goals ├── recordings ├── tips ├── tip_menu_items ├── token_purchases ├── payouts ├── subscriptions ├── subscription_tiers ├── follows ├── devices ├── device_groups ├── device_group_members ├── device_controls ├── chat_messages └── viewer_blocks ``` --- ## Security and Compliance Architecture Security is layered as two nested rings: an outer trust perimeter that validates identity and throttles requests, and an inner compliance and safety layer that enforces regulatory and performer-protection rules. Every request from a client must pass through both rings before reaching business logic. The compliance layer gates on age and performer verification regardless of whether a request is authenticated — an authenticated but unverified user is still blocked from adult content. The safety layer enforces performer-set limits on top of that: even an authorised viewer with verified age cannot exceed the device intensity cap a performer has configured. ``` ┌───────────────────────────────────────────────┐ │ TRUST PERIMETER │ │ │ │ Bearer-token / API-key auth middleware │ │ (per-app app.ts; JWT validation is a TODO) │ │ In-process rate limiting (per-app limiter) │ │ API key validation (broadcaster RTMP keys) │ │ │ │ ┌──────────────────────────────────────────┐ │ │ │ COMPLIANCE LAYER │ │ │ │ Age verification gate (all content) │ │ │ │ 2257 verification gate (performers) │ │ │ │ Content moderation (AI + manual review) │ │ │ │ Geo-blocking (jurisdiction compliance) │ │ │ └──────────────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────┐ │ │ │ SAFETY LAYER │ │ │ │ Device intensity caps (max enforcement) │ │ │ │ Safe-word kill switch (instant stop) │ │ │ │ Consent tracking (per activity type) │ │ │ │ Performer autonomy controls │ │ │ └──────────────────────────────────────────┘ │ └───────────────────────────────────────────────┘ ``` --- ## Cross-Domain Dependencies Aphrodite depends on platform-level shared libraries from `@oshun/*` and the shared event contract from `@oshun/contracts`. It does not depend on other domain libraries (such as `@lilith/*`, `@aje/*`) in its verified `package.json` files. The boundary exists to keep Aphrodite independently deployable: it needs the platform plumbing (database pooling, storage, caching, event bus, error types, logging) but not other domains' business logic. The `@oshun/contracts` dependency is particularly important: it means Aphrodite events are defined using the shared event envelope format, making them consumable by any other domain that subscribes to the event bus without Aphrodite-specific knowledge. The dependencies below appear in verified `package.json` files of `libs/aphrodite/*` and `apps/aphrodite/*`. Not every Aphrodite library uses every one — usage varies per library. | Dependency | Direction | Purpose | | ------------------------ | --------------------- | ----------------------------------------------- | | `@oshun/database` | aphrodite → shared | PostgreSQL pooling, transactions, query builder | | `@oshun/contracts` | aphrodite → contracts | Event envelope schemas, `aphrodite.*` catalogue | | `@oshun/event-bus` | aphrodite → shared | Event publishing over the shared bus | | `@oshun/storage` | aphrodite → shared | S3 / MinIO VOD and asset storage | | `@oshun/cache` | aphrodite → shared | Redis cache utilities | | `@oshun/auth-primitives` | aphrodite → shared | Authentication primitives | | `@oshun/config` | aphrodite → shared | Configuration loading | | `@oshun/logging` | aphrodite → shared | Structured logging | | `@oshun/errors` | aphrodite → shared | Shared error types | | `@oshun/health` | aphrodite → shared | Service health checks | | `@oshun/http-client` | aphrodite → shared | HTTP client | | `@oshun/types` | aphrodite → shared | Shared type definitions | | `@oshun/testing` | aphrodite → shared | Shared test utilities | > Earlier draft documentation also listed `@oshun/auth`, `@oshun/websocket`, > `@oshun/metrics`, `@oshun/rate-limit`, `@aje/nft`, `@aje/payments`, and > `@lilith/llm` as dependencies. These are not present in the reviewed Aphrodite > `package.json` files. Each app's API rate limiting is implemented in-process > in its own `app.ts` (an in-memory limiter), not via a shared > `@oshun/rate-limit` dependency. ## Verification Notes This architecture document was checked against the repository: `apps/aphrodite/*` (17 apps confirmed, all Hono services), `libs/aphrodite/*` (190 directories, ~186 implemented, 4 scaffolds), the Prisma schema (`libs/aphrodite/database/prisma/schema.prisma`), the event contract (`libs/contracts/src/events/aphrodite.ts`), and the `package.json` files of the apps and infrastructure libraries. There is no `services/aphrodite/` tier. App ports are environment-driven and are not asserted here. Cross-domain dependencies are limited to those found in verified `package.json` files. Detailed data-model, event, API, and library-catalogue specifications are in `specifications.md`.