Realtime delivery in XOM means one specific mechanism: the browser holds open subscriptions to database paths, and the server pushes changes to it. There is no polling loop and no request-response refresh cycle for feed content.
01How it works
XOM deploys as a static bundle with no application server at runtime, so the client SDK talks to Firebase directly. Components that need live data attach a value listener to a database path and re-render when that path changes. Every listener is torn down when its component unmounts, which keeps subscription count bounded as a user navigates.
That pattern appears consistently across the platform. The container handler subscribes to a post's node so a post updates in place if its content or type changes. The sentiment container subscribes to the current user's latest text. The blockchain container subscribes to a post's NFT data. Each is a small, scoped subscription rather than a shared global stream.
Writes take the same path in reverse. When the uploader finishes transferring media, it writes one post record to the database, and every client currently subscribed to that region of the tree receives it without asking. Post creation, engagement counters, chat, and presence all move through the same channel.
02The data layout
The Realtime Database holds the high-churn state: post nodes, engagement counters, ad campaigns and their metrics, live session data, and Stories. Rules are applied per node — reads generally require authentication, and ownership-scoped paths restrict writes to the owning user. Anything not explicitly declared is denied by default.
Slower-moving, query-heavy data lives in Firestore instead: user documents, invite codes, administrative configuration, and audit logs. The split is deliberate. Firestore gives indexed queries and role-based rules; the Realtime Database gives low-latency fan-out.
03Server-side triggers
Work that cannot be trusted to a client runs as Cloud Functions — notification dispatch, post processing, administrative callables, and the content proxy. These react to database events rather than to client requests, which is what keeps privileged operations off the browser while preserving the push model.
04Live streaming
The live stream, chat, viewer-tracking, and status routes are defined as API route handlers that read stream records and return status, playback URL, title, broadcaster, and viewer count. Because the production deployment is a static export with no runtime server, those handlers are not served in production. The internal roadmap treats real live streaming as a dedicated piece of work requiring a streaming provider plus Cloud Functions for signaling, behind the broadcast interface that is already built. Verify current status before describing live video as available.