Lilith Metaverse · Guides & deep dives

Lilith Platform Services, Data, and Integrations

Do not infer that apps/lilith is the V3 world server or that the V1 persona-policy library is a network service.

10sections5 minread2tables

On this page

“Lilith platform” can refer to two distinct service estates: the standalone apps/lilith/libs/lilith consciousness product domain, and V3's embodied Rust/TypeScript/Unreal platform. This page maps both and names their integration boundary with V1.

flowchart TB V1[V1 identity memory grounding policy rights and commerce] --> Bridge[Versioned V1 to V3 adapters] LilithApps[Standalone apps and libs Lilith estate] --> ServiceBoundary[Explicit service or content integration] Bridge --> V3Services[V3 Rust world realtime streaming Saraswati and commerce services] ServiceBoundary --> V3Services V3Services --> Protocol[Cross-language V3 protocol and events] Protocol --> UE[Unreal premium client and Pixel Streaming worker] Protocol --> Web[Pixel Streaming entry and Tier 2 web fallback] V3Services --> Stores[(World tenant media commerce and audit stores)] V3Services --> External[TURN SFU GPU CDN payment and media providers] UE --> Evidence[Telemetry moderation provenance and release evidence] Web --> Evidence Stores --> Evidence External --> Evidence

The adapters join systems without renaming them into one estate. V1 remains the account and policy spine; V3 owns authoritative world and realtime behavior; the standalone Lilith service domain crosses only explicit interfaces.

Runtime estates#

Estate Primary paths Shape Responsibility
Lilith consciousness/meditation domain apps/lilith, libs/lilith Web/mobile/desktop/CLI/BFF plus Fastify services and shared libraries. Meditation, conversation/AI, content, voice, progress, commerce, immersive and partner capabilities.
V3 realtime backend apps/v3 Rust world server, realtime gateway, Pixel Streaming relay, Saraswati service, commerce service, shared protocol. World authority, transport/voice, streaming admission, performance and commerce workloads.
V3 web clients apps/v3/lilith-web, apps/v3/lilith-web-fallback Thin Pixel Streaming entry and local three.js/WebGPU fallback. Browser launch and reduced-fidelity participation.
V3 adapters/tenants libs/v3 TypeScript protocol, identity, avatar, audio, policy, tenant, and integration libraries. Cross-language/client adapters and tenant behavior.
V3 premium client V3/ue Unreal Engine 5.5 project, modules, targets, Game Feature data, automation. Native/VR/console/mobile and Pixel Streaming worker runtime.
Shared V1 platform apps/oshun, libs/oshun, cross-domain libraries/contracts BFF, web/admin/studio, identity, memory, grounding, generation, rights, payments, governance. Account and policy spine reused rather than re-created by V3.

Do not infer that apps/lilith is the V3 world server or that the V1 persona-policy library is a network service. The Lilith handbook defines the names.

apps/lilith and libs/lilith#

The Lilith domain includes core BFF/conversation/AI/auth/content/media/ notification/moderation/voice services; meditation and wellness services; content/review/licensing/rights; user/progress/offline/analytics; commerce and partner integration; Web3 services; immersive applications; and operational services. Shared libraries provide configuration, errors/logging, database, cache/queue, Fastify bootstrap, service utilities, events, metrics/tracing, SDKs, and testing/config packages.

The maintained domain index, developer guide, API, database, and architecture are:

Use the generated Docs Center systems, API/contract, data, event, configuration, observability, and ownership references for current code-linked inventories.

V3 service topology#

The world server owns authoritative rooms, presence, interest management, physics validation, and durable world state. The realtime gateway owns authenticated transport, session/resume mediation, and the voice SFU boundary. The Pixel Streaming relay owns capacity/admission and signaller/matchmaker coordination, not rendered frames without a deployed UE GPU worker. Saraswati and commerce services own performance and economic workloads rather than putting them in the world tick.

The clients and services share a versioned protocol and contract registry. The world/gateway reference is World server and gateway.

Contracts and APIs#

Cross-boundary behavior uses typed contracts for launch decisions, identities, rooms/presence, tenant records, avatars, classes, artists/tracks/concerts, commerce/rights, provenance, and operational receipts. A contract records actor and tenant semantics, stable identifiers, versions, validation, error outcomes, and compatibility.

V3 reuses existing V1 BFF capabilities and adds focused launch/realtime surfaces; V3/api is documentation, not a standalone service tree. Start with V3 BFF OpenAPI and the Docs Center generated API and contract reference.

Protocol changes require compatible TypeScript, Rust, and Unreal codecs plus golden fixtures. Client/version negotiation should fail to update/fallback rather than interpret unknown fields unsafely.

Data ownership#

Data Authoritative owner
Account, tenant, identity, entitlement Shared V1 identity/platform service.
Personal memory and consent metadata Iris and consent/data-governance contracts.
Room, presence, entity and physics state V3 world/realtime services, with transient versus durable fields separated.
Tara classes, sequences, instructors, practice plans Tara Studio tenant store/services.
Saraswati personas, tracks, concerts, remix rights Saraswati tenant/service store.
Commons venue/program records Commons/platform tenant store.
Tickets, tips, royalty/settlement records V3 commerce plus Aje/payment authorities.
Provenance, rights, review and takedown Their governed ledgers/services; media stores reference rather than own the decision.
Generated media Object/media store with lineage to the authoritative brief/run/release records.

Shared identifiers and events connect owners; duplicating the same mutable truth across schemas creates drift. Read models and caches declare freshness and can be rebuilt from authoritative records/events.

Events and async workflows#

Events communicate lifecycle transitions such as room/session, class/concert, artifact review/release, rights/takedown, commerce/settlement, and operational incidents. An event envelope should include stable event/aggregate identifiers, tenant, type/version, actor, time, correlation/causation, idempotency, and a schema-owned payload.

Consumers handle duplicates, reordering, poison messages, retry/dead-letter, and replay. A queued or emitted event is not proof that every downstream system applied it; material workflows expose acknowledgments/receipts or reconciliation.

V1 domain bridges#

  • Iris: identity and governed memory/continuity.
  • Sophia: source grounding for teaching, biography, cultural and educational claims.
  • Isis: governed image/video/audio/3D/motion generation.
  • Aja: pose, embodiment, and movement coaching.
  • Psyche: realtime voice/avatar/session behavior.
  • Yemaya: non-realtime media rendering and outputs.
  • Aje: tickets, tips, royalties, settlement, and entitlements.
  • Themis: governed rights, credential, and policy disputes.

Each bridge retains the owning domain's contract and enforcement. V3 does not copy domain policy into the world client.

External integrations#

External surfaces include identity/auth providers, app/console stores, cloud and GPU capacity, WebRTC/TURN, voice and generation providers, object/CDN delivery, payments, C2PA/content credentials, analytics/observability, and distribution/ rights partners. Every adapter defines credentials, tenancy/region, data sent, timeout/retry/idempotency, rate/cost limit, webhook/event verification, degraded behavior, and reconciliation.

Security boundaries#

  • Realtime tokens are short-lived, audience/scope bound, and rechecked on resume.
  • The gateway/world does not trust client transforms, identity, entitlements, or safety decisions.
  • Service-to-service identity and least privilege protect tenant/data owners.
  • Media/provenance URLs do not grant rights to mutate or redistribute assets.
  • Secrets stay in managed configuration and are redacted from logs, traces, prompts, and client bundles.
  • Cross-region data movement follows the account/tenant residency contract.