Live Runtime Proposal

@prox-os/live-runtime is a future package proposal for OS-level presence, rooms, visitor sessions, multiplayer sessions, collaboration sessions, and activity events. The package does not exist yet in the current implementation. This document records the boundary so early UI prototypes can stay aligned without prematurely creating a complex runtime.

Why OS-Level Live Runtime

Prox OS should not treat live behavior as a one-off game feature or a single collaboration app. Presence, visitor logs, rooms, multiplayer games, shared dashboards, launcher spaces, design reviews, and founder workspaces all need similar primitives:

• who is here now;
• where people are gathered;
• what public or shared object is being viewed;
• which actions are safe to record;
• what is short-lived versus persistent;
• which identity state is anonymous, known, or explicitly trusted;
• how privacy and retention policy shape every event.

The future runtime should keep these primitives reusable across OS Home, Visitor App, /app-game, Launcher Hub, Connectors Hub, Design System Hub, and Founder Suite.

Future Package Shape

If the runtime becomes necessary, the proposed package is:

packages/live-runtime/
├─ src/
│  ├─ index.ts
│  ├─ types.ts
│  ├─ room.ts
│  ├─ presence.ts
│  ├─ activity.ts
│  ├─ multiplayer.ts
│  ├─ collaboration.ts
│  ├─ mockRooms.ts
│  ├─ mockPresence.ts
│  └─ mockActivity.ts
└─ README.md

The package name should be @prox-os/live-runtime.

Phase 1 does not create this package. Live Center and Visitor App use local mock data only.

Future Core Types

Runtime Layers

OS Home Presence
├─ online visitors count
├─ avatar stack
├─ current app being viewed
├─ guest / member / owner / collaborator state
├─ recent activity
└─ privacy mode

Live Room Runtime
├─ room id
├─ participants
├─ messages
├─ events
├─ state snapshot
├─ invite policy
└─ lifecycle

Multiplayer Runtime
├─ player slots
├─ spectators
├─ input events
├─ game state snapshot
├─ replay log
└─ reconnect policy

Collaboration Runtime
├─ shared object reference
├─ editor state
├─ comments
├─ cursors or pointers
├─ conflict strategy
└─ audit trail

Future Backend Candidates

These are candidates only. They are not implemented:

• WebSocket room server for low-latency sessions.
• Cloudflare Durable Objects style room coordination for room ownership and state.
• PartyServer-like room abstraction for developer ergonomics.
• CRDT or Yjs-like shared editing for true collaborative editing.
• Database persistence for activity logs, visit logs, retained summaries, and audit events.

The early UI must not imply that any of these systems are running.

Security And Privacy Boundary

Early prototypes must not:

• open realtime sockets;
• create real rooms;
• record raw IP addresses;
• display exact city or precise location;
• generate device or browser fingerprints;
• collect sensitive personal data;
• persist visitor logs;
• infer identity without consent;
• expose unshared app state inside collaboration previews.

Visitor identity upgrade is a future consent-aware model. Trusted collaborator state is an explicit permission model, not a default visitor mode.

Roadmap

Early

• Mock presence.
• Mock visitors.
• Mock rooms.
• Static Live Center UI.
• Redesigned Visitor App UI.
• No real tracking.
• No realtime backend.
• Privacy-first documentation.
• Short-lived demo state only.

Mid

• Real anonymous presence.
• OS Home online count.
• Room lobby for selected games.
• Visitor retention policy.
• Safe activity event model.
• Invite links.
• Read-only live observers.

Later

• Multiplayer runtime for games.
• Co-browsing.
• Shared dashboards.
• Collaborative comments.
• Shared object references.
• Permission-aware rooms.
• Audit trail.
• Optional CRDT-based editing.
• Team spaces and trusted collaborators.