One log, a live feed.

A codemojex room is a sequence of moves, and each one is a real surface in echo/apps/codemojex, every entity carrying its own branded namespace:

• USR — a player account; RMM a room; RND a round, one secret to guess.
• JOB — a guess job on the player’s lane; GES a scored guess written by the authority.
• EVT — a feed entry, one brand per stream, minted host-side by the writer.

The three actions the feed records: a guess submitted — Codemojex.Guesses.submit/3 validates the guess, charges the room’s currency, and enqueues a branded JOB on the player’s lane; a guess scored — Codemojex.ScoreWorker drains that lane, scores with the pure Codemojex.Scoring.score/2, writes a GES guess, and for a classic game publishes a scored event via EchoMQ.Events.publish/5; and a round settled — Codemojex.Settle.close/1 enqueues a settle JOB whose consumer runs Codemojex.Rooms.close_game/1 and pays out.

The feed appends one entry per action. EchoMQ.Stream.append(conn, "cm", "events", fields) mints an EVT-branded record id host-side, derives the explicit XADD id from it by field correspondence, and issues XADD emq:{cm}:stream:events with the branded id stored under the id field. It returns {:ok, branded} — the branded id is the receipt. The writer owns the mint, so there is nothing to spoof, and because successive mints over one writer’s monotone cell strictly increase, the next id always exceeds the stream top: an XADD is never rejected on a single writer, and a wrong-kind id raises before any wire.

To show the feed, read the log and fold it. EchoMQ.Stream.read(conn, "cm", "events", "-", "+") issues XRANGE emq:{cm}:stream:events - + and parses each entry back into {branded, fields_map} tuples in mint order — the branded EVT id recovered from the stored id field, the remaining pairs the payload. The feed is that list reduced to rendered lines: a fold, not a row a worker overwrites, so the same log always renders the same feed. A read moves a cursor, it does not remove an entry, so a reader at the tail and a reader replaying from the start see the same entries.

A windowed view — “the activity of the last five minutes” — is a fold scoped to a slice. Because a stream entry id carries the millisecond it was minted, a DateTime becomes a range bound: read_window(conn, "cm", "events", t0, t1) computes from = minid_floor(t0) and to = maxid_ceil(t1) host-side and reads [t0, t1] inclusive both edges; read_since(conn, "cm", "events", t0) reads [t0, ∞). Time as a range bound is the cursor of R5.01 reapplied — a t0 entry reads back, a t0 - 1ms entry does not.

The visible feed is a fold of the log; the notification side is a consumer. When the feed posts “alex cracked the code”, a notification reader must deliver that to the room — once, and not again on a restart. That is the reader law: EchoMQ.StreamConsumer is a BEAM consumer group over the events stream that reads new entries with XREADGROUP, acks each with XACK, and resumes where it left off. A reader that crashes and restarts with the same name drains its own un-acked backlog first (its PEL, XREADGROUP … 0), then switches to new entries (>), so it recovers exactly what it held; a clean cold start has an empty backlog. A dead peer’s held work is reclaimed by the XAUTOCLAIM beat after an idle threshold.

The handler shape is fun(%{id, payload, attempts, group}) — id the branded EVT receipt, payload the entry’s fields, attempts the per-entry delivery count. The posture is at-least-once: on :ok the entry is XACKed; on {:error, reason} or a raise it is left un-acked and re-delivered. Exactly-once is not claimed, so a re-claimed entry can arrive after a newer one — its branded id is older. The consequence is the one rule the handler must keep: it must be idempotent, and the branded EVT id is the dedup key. Render the line for an EVT id once, record it was sent, and a second delivery of the same id is a no-op. Resume, not replay.

A log that only grows is a leak, so retention is a policy, not a default. EchoMQ.Stream.trim(conn, "cm", "events", {:maxlen, 10_000, true}) issues XTRIM emq:{cm}:stream:events MAXLEN ~ 10000 — keep the ten thousand newest feed entries, remove the older. The ~ approximate form trims in whole macro-nodes: it may under-trim but can never over-trim, so it never deletes inside the window — the safe default. A {:minid, dt, true} window trims by age instead, removing entries minted before dt. The named, opt-in EchoMQ.StreamRetention driver re-applies a declared :policy on a beat through that same public verb; a stream nobody declares is never silently trimmed, and a manual trim/4 call is the equally-supported cadence.

What is trimmed is not lost. EchoStore.StreamArchive.fold/3 folds a mint-ordered slice of the trimmed segment into the native EchoStore.Graft engine’s CubDB — one page per record, in a reserved high page range disjoint from business pages — and advances a watermark W (the branded EVT id of the highest-folded record). The deep feed is then readable beside the live tail: a merge-read splits on W, records at or below it coming from the archive, records above it from the live stream. The fold runs before the trim, so no entry is dropped before it is durable. With a remote configured, the engine replicates the CubDB pages off-box to Tigris behind a create-only commit fence — the durability dial taught end to end, from the volatile bus to the durable floor.