XOM's container protocol is the convention that lets a single post record render as any one of dozens of different interactive experiences. It is a naming contract plus a routing layer, not a network protocol.
01The contract
Every post carries a postType field written as category/type — for example intelligent/sentiment, elements/blockchain, or collaborative/live-polls. The uploader writes this value when the author picks a content type; the container handler reads it when the post is opened.
Six categories are defined, and each holds a set of modules:
| Category | Purpose | Examples | |---|---|---| | collaborative | Real-time multi-user content | documents, messaging, live polls, multiplayer | | dynamic | Responsive and algorithm-driven formats | streaming, podcast, galleries, dimensional, artificial | | elements | Interactive components inside content | animation, blockchain, gamification, quizzes, surveys | | external | Third-party and embedded content | embedded, interactive, standard | | intelligent | AI-assisted experiences | content, experience, recommendation, sentiment | | programmable | Developer and power-user types | applications, assistants, code editors, digital tools, visualization |
02The routing layer
The container handler holds a two-level map from category to type to component. Every entry is a lazy import, so a container's code is fetched only when a post of that type is actually opened. This matters at the scale of the taxonomy: without it, every visitor would download every container implementation regardless of what they viewed.
Resolution runs in a fixed order. The handler subscribes to the post node and reads three fields: postType, postMeta, and postURL. If postURL is present, the post renders as an embedded web view in an iframe and no container is loaded. Otherwise postType is split on the slash and looked up in the map. On a match, the component is mounted inside a suspense boundary with a loading state, and receives a config object containing the post ID and the post metadata. On no match, the handler renders an explicit unknown-content-type message rather than failing silently.
That config object is the whole interface between the routing layer and a container. A container receives an identifier and a metadata string, and is responsible for fetching whatever else it needs. This is why containers can be added without touching the handler beyond one map entry.
03Bridging to external systems
A separate bridge component synchronizes media from an external media service into a post node, writing the retrieved payload back under the post record and exposing an explicit sync status. This is the pattern intended for cross-system content flow: an external system's data is fetched, normalized, and stored against the post, so that containers continue to read from one place.
The internal roadmap identifies a documented public read contract — a stable way for sibling systems to consume XOM feed and profile content without coupling to its internal storage — as work still to be done.