[Celerity][P1] Prove Product-native room realtime without breaking guest access

[knzeng-e]

Outcome

Prove that Celerity (Polkadot Statement Store) can carry progressively richer Dotify room presence and social events while preserving link-first, wallet-free listening and the current room reliability bar.

Why this is a separate sprint

The first Celerity slice only publishes and reads bounded room-discovery beacons. Replacing more of the realtime layer changes delivery, identity, privacy, ordering, admission and recovery guarantees. That work needs measured dual-transport evidence before Socket.IO authority can be reduced.

Scope

• Introduce a typed RoomRealtimePort boundary around discovery, room lifecycle, social events and session control.
• Classify every event by the guarantee it needs: best effort, ordered, acknowledged, private, host authoritative or atomically admitted.
• Add an opt-in Celerity transport for Product participants, initially in observation or dual-publish mode.
• Define compact, versioned envelopes with message identity, producer sequence, expiry, deduplication and replay protection.
• Add application-layer encryption for private chat or direct signaling before those payloads use Celerity.
• Measure presence, reactions, requests, chat and player-state convergence before considering join or WebRTC signaling.
• Keep Socket.IO available for anonymous browser guests and as the fallback until Celerity proves equivalent user-visible reliability.
• Run a bounded SDP/ICE feasibility spike using the limits of the pinned Product SDK; do not assume fragmentation is acceptable without evidence.
• Evaluate Product Host ChatManager for invitations, artist-session notices and action buttons without coupling Dotify's in-room chat to an unsettled Host surface.

Product invariants

• Opening a room link must not require a wallet, Product account or blockchain knowledge.
• WebRTC/TURN/SFU remains the audio transport; no audio or protected source key enters Celerity.
• The host remains authoritative for playback and queue changes.
• A delayed, duplicated or missing statement must converge safely and must never reopen protected access.
• No public statement contains listener identity, wallet address, plaintext private chat, content key or durable location history.
• Dotify must distinguish recent signed presence from confirmed room reachability.

Acceptance evidence

• Two real Product clients exchange the selected Celerity event classes on the same candidate build.
• Recorded latency, loss, duplicate, reorder, reconnect and expiry behavior under foreground, background and network-change scenarios.
• Socket.IO-only, Celerity-enhanced and degraded/fallback paths have deterministic tests.
• Anonymous web guests still join and listen through the canonical room link.
• Critical player and queue state converges after message loss or reconnection.
• The sprint ends with an explicit decision matrix: migrate, keep hybrid, or retain Socket.IO for each event class.
• Any Socket.IO responsibility removed has equivalent operational diagnostics and rollback.

Non-goals

• No immediate full replacement of Socket.IO.
• No media relay through Statement Store.
• No durable chat history or permanent social graph.
• No requirement that guests acquire a Product identity.
• No default activation before live evidence and rollback are reviewed.

Dependencies and references

• Depends on the accepted W13 pilot candidate and the merged Celerity room-beacon reader.
• Coordinates with Product compatibility epic [Product SDK][P1] Prove Product host compatibility before integration #85 and room resilience [Rooms][P1] Productionize WebRTC with TURN, quality metrics, and an SFU path #89.
• Local implementation prompt: docs/backlog/implementation/W27-celerity-room-realtime.md.