Streaming, Cross-Version Incarnation & Live Service

A creator republic only stays alive if three loops keep turning. A character has to outlive any one realm — and any one Oshun product version — or "your character" is just a save file a server operator can hold hostage. A live audience has to be able to watch, clip, and stream a realm safely, because the genre this whole product descends from — GTA/FiveM roleplay — became the state of the art of emergent multiplayer through livestreaming, not in spite of it. And the platform has to keep a programming rhythm going — spotlights, events, grants, governance cycles — so the supply of good realms never runs dry. This page covers the "Continuity & Live Service" group: the Ori bridge that carries a V7 character into V2–V6 and realm-to-realm, the streaming / spectating / creator loop, and the live-service programming wrapped around them.

The honest shape of this cluster is unusual. The continuity half is the most genuinely-compiled code in V7 — libs/v7/substrate-bridge is real Rust that links the V6 Ori event store and runs a cross-version round-trip under injected faults. The creator-loop half is half-shipped: analytics and replay-clip moderation evidence are real and test-pinned; streamer mode and the spectator path are designed contracts on real substrates. The live-service half is mostly platform programming riding on real decision kernels rather than running services of its own. This page follows the code where the prose runs ahead of it, and labels every seam. For the full V7 scope, start at the hub: ../V7_features.md.

What ships, honestly#

• The Ori cross-version bridge is real, compiled Rust. libs/v7/substrate-bridge/src/lib.rs (~2,460 lines, eight #[test] blocks) mints scoped incarnation passports, runs the cross-version round-trip eval, and opens the realm-federation corridor. Its Cargo.toml carries real path dependencies on egbe-ori-service and ori-model, so the V6 Ori event store, projection materializer, and audited operator-read path are compiled in and exercised, not stubbed.
• The identity/privacy substrate that streamer mode needs is real. The V7IdentityFirewall projects a platform principal into an opaque per-realm handle, and run_trust_boundary_eval / run_webview_escape_eval prove that platform secrets never reach realm code or a creator web view. Both are pinned by passing tests.
• Creator analytics is a real, deterministic dashboard. libs/v7/contracts/src/creator-analytics.ts — evaluateV7CreatorAnalyticsDashboard() — computes DAU/retention/playtime/ funnel/revenue/per-mod engagement with exact asserted numbers in index.test.ts. It would fail on a stub.
• Replay clips as moderation evidence are real. apps/v7/sekhmet-scanner validates a server-signed replay clip attached to a report and rejects bare accusations without it.
• What is designed, not shipped: streamer mode as a named privacy toggle (hide join code/IP, anti-stream-snipe delay), the delayed read-only spectator path, clip export as creator content, and the live-service programming calendar (spotlights, platform events, grants). These are contracts on top of the real substrates above, called out inline below.
• Honest mock seams: anything "Themis-signed" is a reference string plus a boolean today (Themis is Mock), and the V1 identity binding is a local StaticIdentityProvider, not the live @oshun/identity wire.

Cross-version incarnation and the Ori#

The principle: the Ori is the truth, a realm is a stage#

A V7 character is not a realm's property. It is a NanaCharacterRecord (libs/v7/nana) keyed by an ori_id that points at a V6 Ori identity record — the genuine source of truth. The bridge's only job is to let that identity be rendered into other Oshun product versions while the Ori root stays singular and intact. As the architecture puts it: the Ori remains the truth; a realm, like any incarnation destination, is a stage the character is rendered into. That single sentence is what the whole continuity stack enforces in code.

Five destinations, per-destination capability mapping#

V7AyeIncarnationDestination enumerates the five V-destinations a character may travel to: V2Maya, V3Lilith, V4Odysee, V5Oshun, and V6OriNative (the native Ori return path). Each carries a stable adapter_ref (v2-fighter, v3-citizen, v4-operator, v5-companion, v6-ori-service-native) and a versioned capability_mapping_ref (e.g. capability-mapping:v3-lilith:citizen:v1). The version-suffixed mapping is the load-bearing detail: a character's abilities are re-mapped per destination, not copied verbatim — a V2 fighter is not the same capability surface as a V3 metaverse citizen. default_v7_aye_incarnation_destinations() returns the full inventory — the V6 Aye Bridge incarnation model carried into V7, plus one new corridor: federation, below.

Minting a scoped passport: data minimisation by construction#

mint_v7_character_incarnation_passport() produces a V7CharacterIncarnationPassport, and two design choices matter. First, the passport carries only what the destination needs. scoped_claims_for_character() emits exactly four claims — identity.display, identity.characterKey, capabilities.mappingRef, and ori.memoryIndex — and nothing else: not the character's NanaBalances, not its full record, not its relationships. Second, integrity is hashed: ori_root_integrity_hash() binds the ori_id, the stable character key, and the scoped claims into an ori_integrity_hash that must survive every subsequent lease, fault, and concurrent claim untouched. The test passport_eval_round_trips_… asserts the negative case: no scoped-claim value contains user:v7:abeni or session:v7:mawu, so platform identifiers provably cannot ride along inside the passport.

The round-trip eval: integrity under fault and concurrency#

round_trip_v7_character_into_destination() exercises the full journey — departure → destination actor → return → incarnation-journal write-back — and it is adversarial by design. It injects a disconnection during return and recovers via a return_replay_buffer_ref; it fires a concurrent duplicate departure against the same Ori and asserts concurrent_departure_blocked; and it checks that after the dust settles there is exactly one authoritative Ori copy (active_ori_copy_count == 1) and zero lingering destination copies. round_trip_ok() returns true only when the copy counts hold, the duplicate was blocked, ori_integrity_hash_before == ori_integrity_hash_after, and the evidence proves both round-trip-integrity and incarnation-journal-writeback — i.e. the trip is recorded back into the Ori biography. It is the same "no window with two writers or zero owners" discipline the realm mesh uses for authority handoff, applied to identity. And because the V6 Ori store is compiled in, the underlying write (EgbeOriFacade::write_character_record) really appends a MemoryFormed event to a PartitionedPostgresOriEventStore and reads it back through the audited operator_read_ori_projection path — the bridge does not fake the identity store it claims to use.

The new V7 corridor: realm-to-realm federation under treaty#

V7 adds one corridor the prior versions did not have: realm-to-realm federation. V7RealmFederationTreaty::themis_signed() defines a corridor between two realms with an explicit allowed_state_keys set and a lease_ttl_seconds; the default treaty permits only presence.status, position.cell, party.intent, and realm.quest_state for 900 seconds. open_v7_realm_federation_corridor() then filters the source realm's state down to exactly those keys, hashes the negotiated subset, and sets out_of_scope_state_rejected true only when there genuinely was state outside the treaty that got excluded (the test seeds platform_user_id and ori_private_memory precisely to confirm they are dropped). Honest seam: themis_signed is a constructor that sets a boolean and copies a terms reference — the corridor's governance contract is real and validated, but no live Themis call signs it yet, because the Themis substrate binding is Mock. run_v7_passport_eval() is the single gate that composes both legs (V-destination round-trip with disconnection and federation corridor with disconnection) and asserts four properties: both round-trips OK, Ori integrity preserved under disconnection, and concurrency preserving the Ori root.

How shared identity composes#

The passport's authority chain begins at the platform principal. A V7AuthenticatedPrincipal carries user_id, tenant_id, session_id, scopes, and a residency scope — the same claim shape an @oshun/identity (libs/shared/identity) JWT issues for every other Oshun product, where the real library ships JwtService, auth middleware, mTLS verification, and account binding. V7's binding to that layer is currently the Mock StaticIdentityProvider, so the shape is the shared one while the wire is a local stand-in. On top of it sits the continuity guarantee: V7IdentityFirewall.project() turns the platform principal into a V7RealmScopedIdentity whose opaque_handle is an HMAC-SHA256 of (pepper, schema_version, tenant_id, user_id, realm_id) — so a realm sees a per-realm pseudonym, never the platform account, and the same player in two realms gets two un-linkable handles (asserted by identity_firewall_eval_blocks_platform_identity_leakage).

Streaming, spectating & the creator loop#

V7 treats streaming as a first-class loop; the four pieces below land at different points on the shipped/designed line.

Streamer mode and the privacy substrate#

Streamer mode, as a player-facing toggle, is designed: hide the streamer's exact join code/IP and account info, with a configurable anti-stream-snipe match-start delay. But the redaction floor it stands on is real, compiled, and adversarially tested. run_trust_boundary_eval builds the sanitized contexts a realm process and a creator web view may inspect, then runs a hostile-operator corpus probing for the platform session token, the payout credential, the real-money entitlement, and raw field names like Authorization and payoutCredential — the eval passed() only when none are reachable from either surface (trust_boundary_eval_isolates_platform_secrets_from_realm_and_web_view). run_webview_escape_eval independently proves a locked-down creator web-view policy (default-src 'none', native APIs disabled, HTTPS-only fetch allow-list) blocks file-scheme loaders, operator-endpoint exfiltration, arbitrary native-API calls, and data:-URL inline scripts. With the identity firewall's opaque per-realm handles, that is the substance behind "streamer mode": a broadcasting player's identity and the operator's secrets are already provably un-reachable from the surfaces a stream exposes — the toggle is the missing UI layer over an existing guarantee.

Spectating#

The spectator path is designed: a delayed, read-only stream that reuses the realm's interest-managed delta stream so communities watch live events without affecting authority, governed by per-realm policy and an anti-spoiler delay. The substrate it rides on is real — the server-authoritative realm netcode and interest management in ../architecture/moremi-realm-server-and-netcode.md — but the overlay itself is a contract, not yet a shipped service. The read-only framing is the integrity promise: a spectator consumes the delta stream, it never writes into the simulation.

Replays and clips: moderation evidence (real) and creator content (spec)#

The clip system splits cleanly. Its moderation-evidence half is real code. apps/v7/sekhmet-scanner declares a replay-clip-evidence-attachment capability, and evaluate_sekhmet_contextual_report_flow() will accept a report only when an accusation, valid telemetry, and a valid replay clip are all present — otherwise the decision is RejectedBareAccusation. A clip is valid (sekhmet_replay_clip_evidence_is_valid) only when its realm_id matches the report, its end_tick > start_tick, its content_hash starts with sha256:, and crucially it is signed_by_authoritative_node and reproduces_incident — the V5 "Replay Theater" pattern turned into hard evidence: you cannot report on a hunch or forge the clip, because only a server-signed capture that reproduces the incident counts. The wider trust-and-safety pipeline this feeds is in ../architecture/sekhmet-safety-and-anti-cheat.md. The creator-content half — exporting a clip, a photo-mode shot, or a short for the social loop — is designed, layered on the same server-side capture.

Creator analytics#

The creator-analytics dashboard is real and deterministic. evaluateV7CreatorAnalyticsDashboard() (libs/v7/contracts/src/creator-analytics.ts, schema v7.creator-analytics.1) takes per-realm samples and computes the full Roblox/UEFN-class surface: DAU/WAU/MAU, retention at day-1/7/30 in basis points, playtime (average/median/p95), per-stage funnel conversion with drop-off, a revenue breakdown across the four rails (engagement_pool, direct_sale, subscription, dependency_revenue), and per-mod engagement carrying a retentionLiftBasisPoints so a mod that hurts retention shows up negative. It rolls those into a DAU-weighted summary, assigns each metric a healthy | watch | page status against creator targets, and emits concrete actions (improve-day7-retention, recover-revenue-target, repair-funnel-<stage>, review-mod-<id>). This is not decorative: the test "reports creator analytics across DAU retention playtime funnel revenue and per-mod engagement" pins exact outputs — totalDau: 2430, weightedDay7RetentionBasisPoints: 6459, totalGrossRevenueCents: 1442000, averageRevenuePerDauCents: 593, the d7-return funnel stage at 6841bp with a watch status, the engagement_pool rail at 484000c / 5748bp — numbers a stub could not reproduce. This is what closes the creator loop: it tells a creator what to fix, and what it rewards (multi-day retention, real engagement) is exactly what the engagement-payout economy in ./abundantia-creator-republic.md weights.

Live-service and community programming#

V7's live service is largely community-run, with Oshun programming only the platform-level rhythm — the most spec-heavy part of the cluster, though each piece rides a real decision kernel rather than inventing a parallel one.

• Creator spotlights and featured realms — a weekly, curator-selected rotation surfacing standout realms and Collections (the V5 featured-slots model), feeding the in-game browser and loading rotation. The eligibility signal behind a feature is real: a realm reaches Verified only by surviving the Maya Crucible adversarial economic-balance check and clean Sekhmet / moderation standing (evaluateMayaRealmVerifiedGate), detailed in the arch companion. Featuring is the programming layer; the gate underneath it is code.
• Platform events — synchronous platform-wide moments (the Fortnite live-event lesson) realms can opt into, plus seasonal creator challenges with engagement-pool boosts. The boosts flow through the same anti-fraud payout machinery in ../architecture/abundantia-economy-firewall-and-anti-fraud.md, so an event cannot become a bot-farm payout amplifier.
• Creator programs — incubation/grants for promising creators (the Roblox Jumpstart / Epic Support-A-Creator model) and a verified-creator track with auto-approve distribution and elevated payout visibility, to sustain content supply — the analytics dashboard above being the instrument a program manager reads to decide who graduates.
• Governance cadence — scheduled Eunomia cycles give platform-level proposals a predictable venue. The governance engine those cycles run on is real, test-backed Rust/TS (the tier model, the safety floor no vote can cross, the six plural-voting formulas, and the appeal-to-Themis route) — but it is a decision kernel awaiting its transport, documented honestly in ../architecture/eunomia-governance-and-ori-bridge.md.

The through-line: the live-service programming is the last mile, not the foundation — it rides on kernels that already decide correctly (the Verified gate, the analytics dashboard, the anti-fraud payout pools, the Eunomia tally formulas).

How it connects#

The three loops on this page share one spine: the platform owns identity and trust, the realm only ever holds a scoped rendering. A streamer's account and an operator's secrets are un-reachable from realm code because the trust-boundary eval proves it; a spectator sees a read-only delta and can never write the sim; a moderation clip counts only when an authoritative node signed it; and a character survives any realm — and any Oshun version — because the Ori is the truth and the passport carries only four scoped claims across the boundary. The continuity code is compiled and fault-tested today; the streamer toggle, spectator overlay, clip export, and live-service calendar are designed contracts on substrates that already exist; and every "Themis-signed" or live-@oshun/identity seam is structurally correct but still mocked. For the full V7 feature scope, return to the hub: ../V7_features.md.

Related#

• Pheme Voice & Hera Social Graph — the voice and crew planes a streamer broadcasts; a Hera crew rides the same Ori passport into V2–V6, and streamer-mode redaction protects a broadcasting voice.
• Platform, Accessibility, Localization & Launch — the accessibility parity for voice/captions a stream must preserve, the launch-locale set the spotlights and catalog localize across, and the platform readiness floor.
• Eunomia Governance & the Ori Cross-Version Bridge — the engineering companion for everything on this page: the passport mint and round-trip eval in full, and the governance kernel the live-service cadence drives.
• Moremi: The Server-Authoritative Roleplay Framework — the realm authority and interest-managed delta stream the spectator path reuses.
• Abundantia — The Creator Republic — the engagement-payout economy the analytics dashboard feeds and the anti-fraud the live-service incentives ride on.
• The feature hub: ../V7_features.md