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/<name> 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.

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.

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).

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.

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.

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.

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.

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.

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.

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.