Presence And Collaboration
Prox OS needs shared language for presence, visitors, rooms, multiplayer,
Prox OS needs shared language for presence, visitors, rooms, multiplayer, collaboration, and activity before any realtime backend exists. These concepts are related, but they should not collapse into one generic "live" feature.
Concept Boundaries
| Concept | Core question | Typical UI | Persistence |
|---|---|---|---|
| Presence | Who is here now? | Online avatars, active app, current viewers. | Short-lived |
| Visitor Log | Who visited recently? | Anonymized activity feed, visit count, broad source. | Limited retention |
| Room | Where are people gathered? | Room lobby, participants, invite link, status. | Mixed |
| Multiplayer | How do multiple people interact in a game or realtime session? | Player slots, inputs, spectators, game events. | Session plus optional replay |
| Collaboration | How do multiple people work on the same object? | Shared object, comments, co-browsing, editing state. | Usually persistent |
| Activity | What happened? | Event timeline, app opened, room joined, note added. | Policy-controlled |
OS-Level Model
Prox OS is not a single collaboration app. The OS should expose reusable live capability to many surfaces:
- OS Home can show that a public space feels alive.
- Visitor App can summarize privacy-first visitor activity.
- Game apps can add room lobbies and spectators later.
- Launcher Hub can support shared web spaces and co-browsing later.
- Connectors Hub can support schema review rooms later.
- Design System Hub can support recipe review sessions later.
- Founder Suite can support trusted reviewer rooms later.
This is why the future proposal is @prox-os/live-runtime, not a game-only
backend or a visitor-only analytics store.
OS Home Presence
OS Home should eventually make visitors feel present without becoming invasive. The safe public model can show:
- online visitor count;
- anonymous avatar stack;
- current public app being viewed;
- broad source category;
- broad region;
- recent public activity;
- privacy mode indicator.
It must not show raw IP addresses, exact city, precise location, private app state, fingerprints, or sensitive personal data by default.
Identity States
Presence and Visitor Log should support three identity states:
- Anonymous visitor: the default for public OS Home, public docs, and public app previews.
- Known user: a future signed-in or explicitly identified user governed by account privacy settings.
- Trusted collaborator: an explicitly authorized collaborator with scoped room or shared-object permission.
Trusted collaborator state must never be inferred from anonymous visits.
Relationship To Activity
Activity is the policy-controlled record of what happened. Presence can be short-lived and never persisted. Visitor Log can retain only broad anonymized events for a short period. Collaboration may persist comments or audit events only when the shared object and permission model justify it.
Roadmap
Early
- Static Live Center UI.
- Visitor App redesigned around privacy-first presence.
- Mock presence, visitor, room, multiplayer, collaboration, and activity data.
- No real visitor tracking.
- No realtime backend.
Mid
- Anonymous presence for selected public OS Home surfaces.
- Retention policy for Visitor Log.
- Safe activity event schema.
- Invite links and read-only observers for selected rooms.
Later
- Permission-aware rooms.
- Shared dashboards.
- Co-browsing.
- Collaborative comments.
- Optional CRDT-based editing.
- Audit trail for trusted collaboration.