UC_4.9.1: Discord Chat Stream (ONE-WAY)

---

Document References

---

1. Overview

References/Wireframe/Stage 2/Community & Live Broadcast/Community (with data).webp Community page, broadcast Live — chat panel with message feed and the locked input row. Note: the green 38 online pill visible in this wireframe is obsolete and must not be built (Ref: BR_4.9.1.11).

References/Wireframe/Stage 2/Community & Live Broadcast/Community (no data).webp Community page, broadcast Offline — chat panel in the No live chat empty state.

2. Trigger

• The trader navigates to the Community page via the Community tab in the persistent sidebar (Ref: UC_4.1.2 §2 Screen Description) → the chat component mounts and issues its one-time hydration request (Ref: BR_4.9.1.4).
• A new message is posted in the Discord #live-broadcast-chat channel → the DISCORD_CHAT_STREAM webhook pushes it to the Dashboard over WebSocket (Ref: BR_4.9.1.5).

3. Pre-conditions

• The user is authenticated and is on the Community page.
• GET /community/live-broadcast has returned the current is_live value. This endpoint and its contract are owned by UC_4.5.1 and are not redefined here (Ref: BR_4.9.1.3).
• The account is a SIM (Evaluation) account at Level 0. No Discord account linking is required to read the feed (Ref: BR_4.9.1.1).

4. Post-conditions

• The panel renders in exactly one of two states: Live — read-only feed with the input row locked, or Offline — No live chat empty state (Ref: BR_4.9.1.3).
• No message originating from the SIM trader is ever transmitted to Discord.

5. Basic Flow — Broadcast Live (SIM read-only)

1. The Community page renders. is_live == true is returned by GET /community/live-broadcast (Ref: UC_4.5.1 §5), so the chat panel opens together with the video player.
2. On component mount, the frontend executes a single hydration request and renders the 50 most recent messages held in the backend Redis cache, so that the panel never loads empty (Ref: BR_4.9.1.4).
3. The frontend opens the DISCORD_CHAT_STREAM WebSocket subscription. Every message posted in #live-broadcast-chat arrives as an individual payload { author, message_text, timestamp, is_host } and is appended to the bottom of the list in real time, one-to-one, with no batching and no delay (Ref: BR_4.9.1.5). The stream carries append events only — an edit or a deletion made afterwards in Discord does not reach the panel (Ref: BR_4.9.1.14).
4. Each message renders as a bubble showing the author's Discord server nickname with its role suffix, the message body, and the message time (Ref: BR_4.9.1.6, BR_4.9.1.7). The author name is styled from the is_host flag on that payload — gold when is_host == true, standard white otherwise (Ref: BR_4.9.1.13).
5. A message whose body exceeds four rendered lines is truncated and offered with a Read more control; expanding it reveals the full body inline, within the panel's fixed height, and exposes a sticky read less control at the bottom right (Ref: BR_4.9.1.9).
6. As messages arrive, the list scrolls according to the trader's current scroll anchor — auto-scrolling when anchored at the bottom, or holding position and surfacing a New Messages badge when the trader has scrolled up to read history (Ref: BR_4.9.1.8).
7. Once the list exceeds 50 messages, the oldest DOM nodes are purged so that the window stays fixed at the 50 most recent messages. There is no pagination and no infinite scroll for older history (Ref: BR_4.9.1.4).
8. The message input and the Send control remain locked for the entire session. The input cannot receive focus and the Send control cannot be activated, regardless of how long the trader stays on the page and regardless of whether their Discord account is linked (Ref: BR_4.9.1.2).

6. Alternative Flow — Broadcast Offline

Applies whenever is_live == false.

1. The chat panel clears the active messages and transitions to the empty state.
2. The panel body displays No live chat with the supporting line Chat will open when the session goes live.
3. The input row stays present but locked, and its placeholder changes to Waiting for session... (Ref: BR_4.9.1.2).
4. When the broadcast returns to is_live == true, the panel re-opens and the flow restarts at §5 step 2 — the feed is re-hydrated from Redis; cleared messages are not restored from the client (Ref: BR_4.9.1.3).

7. Exceptional Flow

• [If AutoMod blocks a message before it is published in Discord] — it never enters the WebSocket stream. No message, notice, or placeholder is rendered in the panel; from the Dashboard's perspective the message never existed (Ref: BR_4.9.1.10).
• [If a message is edited or deleted in Discord after it has been broadcast] — the panel keeps the original message unchanged until the rolling window purges it or the broadcast goes offline (Ref: BR_4.9.1.14).
• [If a message carries an image, video, file, GIF, or sticker] — the media is stripped by the backend and only message_text is rendered. If the message carried no text at all, the backend drops it entirely and nothing is rendered in the panel (Ref: BR_4.9.1.7).
• [If a message contains a URL] — it renders as plain, non-clickable text (Ref: BR_4.9.1.15).
• [If a message contains a custom Discord server emoji] — it renders as the raw text string. Standard Unicode emojis render natively (Ref: BR_4.9.1.7).
• [If a message contains an @ mention] — it renders as plain text. No tag is resolved and no notification is raised in the Dashboard (Ref: BR_4.9.1.7).
• [If the trader reopens the Community page mid-session] — the panel re-hydrates from the Redis cache with the last 50 messages; it never loads empty while the broadcast is live (Ref: BR_4.9.1.4).

8. Business Rules

BR_4.9.1.1: Feed Visible to All Accounts — Posting Gated by Discord Role

The chat feed itself is universal: #live-broadcast-chat has its public access set to Read-Only, so the stream of messages is globally visible to every authenticated user on the Dashboard, SIM and LIVE alike. There is no hidden state, no locked overlay on the feed, and no upsell placeholder in place of the panel.

Posting is a separate privilege and is gated on the Discord channel's User Scopes (Source: Discord Server Details.md §#live-broadcast-chat):

The Associate Trader role starts at Level 1 (Source: Discord Server Details.md §Compiled Discord Roles and Badges — Associate Trader = Levels 1 to 5). A SIM trader is still in the evaluation phase at Level 0 and therefore holds only the Public (Read) scope. This is why the panel is ONE-WAY for SIM.

The lock is derived from the account's level/track, not from the Discord linking state. Linking a Discord account does not raise a SIM trader above Level 0 and therefore never unlocks posting on this panel (Ref: BR_4.9.1.2).

BR_4.9.1.2: Locked Input Row for SIM — Permanent, Single State

For a SIM account the message input and the Send control are rendered in a disabled, locked state. They are not removed from the layout — keeping the row in place preserves the panel height and the page grid.

• The input cannot receive focus and accepts no keystrokes. The Send control is disabled and performs no action on click.
• Placeholder while the broadcast is live: Pass the Associate Track to unlock chat
• Placeholder while the broadcast is offline: Waiting for session...
• The locked state is permanent for the whole SIM phase. It has exactly one appearance per broadcast state — it does not vary with the trader's Discord linking state, session length, or account risk status.
• Because no message can be composed, the outbound-only rules — the 2,000-character maxlength, the per-user rate limit and its inline notice, and the Enter / Shift+Enter submission keys — have no effect in this UC and are not restated here (Ref: BR_4.9.1.12).

BR_4.9.1.3: Chat Lifecycle Bound to the Broadcast is_live Flag

The chat panel opens and closes at the exact same moment as the video broadcast. Both components are driven exclusively by the is_live flag returned from GET /community/live-broadcast. There is no separate schedule, field, or flag that could open the chat earlier or hold it open later than the player.

• The endpoint contract, the call cadence, and the conditions under which the frontend observes a change of is_live are owned by BR_4.5.1.3 and are not duplicated here. The chat panel changes state at the same instant the player does, by construction.
• On the transition to offline, the panel clears the active messages immediately and switches to the empty state described in §6. Messages are not retained as a read-only archive, and no post-session or intermediate state exists.
• On the transition back to live, the panel re-hydrates from the Redis cache (Ref: BR_4.9.1.4). Cleared messages are never restored from client memory.

BR_4.9.1.4: Hydration and Fixed 50-Message Rolling Window

• Hydration: on initial component mount the frontend executes a single request that loads the 50 most recent messages from the backend Redis cache, so the panel does not load empty.
• Rolling window: the panel maintains a fixed DOM window capped at the 50 most recent messages. Older nodes are purged as new messages arrive, to preserve browser memory.
• No pagination and no infinite scroll. Messages older than the rolling window are not reachable from the Dashboard. Scrolling up within the window is supported and is a read affordance available to SIM traders (Ref: BR_4.9.1.8).

BR_4.9.1.5: Inbound Streaming — Real-Time 1:1 WebSocket, FIFO Ordering

Messages travel from Discord to the Dashboard over the DISCORD_CHAT_STREAM WebSocket in real time, one payload per message. Batching applies exclusively to the outbound direction (Dashboard → Discord) and never to the inbound stream rendered here.

• The outbound pipeline — a Discord Webhook route with a bot-batching fallback — is owned by BR_4.14.1.3. Neither route touches the inbound contract on this page.

• ⚠️ Open. A message posted through the webhook route carries no Discord role metadata, so author and is_host cannot be read from it. How the backend resolves those two fields is UC_4.14.1 §10 item 15.

• WebSocket payload:

  { "author": "string", "message_text": "string", "timestamp": "ISO8601", "is_host": boolean }

  Field	Type	Description
  author	string	The author's exact Discord server nickname (Ref: BR_4.9.1.6)
  message_text	string	Raw message body, plain text (Ref: BR_4.9.1.7)
  timestamp	ISO8601	UTC receipt timestamp. Ref: CR-08
  is_host	boolean	true when the author holds the Discord role named exactly Host, otherwise false. Drives the gold name highlight (Ref: BR_4.9.1.13)

• Ordering: messages are sequenced First-In, First-Out on UTC receipt timestamp; display order is guaranteed to match send order. Ref: CR-08.

BR_4.9.1.6: Display Name Composition — Discord Nickname Plus Role Suffix

The name shown on a message bubble is the author's exact Discord server nickname, delivered in the author field of the WebSocket payload. Role designations such as Coach or Mentor are appended automatically from the user's assigned Discord role metadata.

• The backend does not generate custom hashes, anonymised IDs, or separate handle fields. A name such as Trader 0x4F is the nickname the user set on Discord, not a system-generated identifier.
• A trader cannot set, change, or self-label their display name or avatar from the Dashboard, and there is no chat-identity setting anywhere in the product. A regular trader cannot present themselves as a coach.
• Identity source depends on where the message was typed. A message typed natively in Discord carries the linked Discord profile. A message sent from the LIVE Dashboard goes out through a Discord Webhook whose username and avatar_url the backend fills from the Users record, so the name and photo shown in the Discord app are Dashboard-sourced (Ref: BR_4.14.1.12). Either way the values are derived server-side — the trader chooses nothing.
• The visual style applied to that name (gold vs. white) is a separate concern and is not derived from the nickname text. It is driven solely by the is_host flag on the payload (Ref: BR_4.9.1.13).

BR_4.9.1.7: Content Rendering Constraints — Plain Text and Unicode Emoji Only

The panel is a lightweight text relay, not a Discord client. It renders exactly one field of the payload — message_text — as an unformatted text string.

No custom emoji picker is built into the Dashboard; on the LIVE side, composing traders use their operating system's native emoji keyboard.

Media-only message. A Discord message carrying only media arrives with an empty message_text. Once the media is stripped there is nothing left to display, so the backend drops the whole message — it is never broadcast on DISCORD_CHAT_STREAM. The panel renders no empty bubble and no placeholder.

BR_4.9.1.8: Auto-Scroll Anchoring and the New Messages Badge

Standard chat view logic applies, and it is fully available to SIM traders — scrolling and reading are not part of the ONE-WAY restriction (Ref: BR_4.9.1.2).

• [If the trader's scroll position is anchored at the bottom of the container] → the list auto-scrolls downward as new messages arrive.
• [If the trader has scrolled up to read history] → the scroll position is maintained and a small, clickable New Messages badge is displayed at the bottom of the container. Clicking it jumps the list to the newest message and re-anchors the view at the bottom.
• The badge is displayed only while the trader is scrolled away from the bottom, and disappears once the view is re-anchored.

BR_4.9.1.9: Long Message — Inline Read more / read less

A message whose rendered body exceeds four lines is truncated in the bubble and offered with a Read more control at the end of the visible text.

Truncation threshold. The limit is 4 rendered lines, applied identically at every breakpoint — it is not a fixed character count.

• The panel width changes between breakpoints, so a fixed character count would produce a different bubble height on every screen. A line clamp keeps the visual weight constant everywhere.
• Message bodies carry Unicode emoji (Ref: BR_4.9.1.7), where one glyph spans several code units, so a character count would also mis-measure the visible length.
• ≈280 characters is the reference equivalent at the desktop panel width (~55–65 characters per line × 4). This figure is for client communication and test-data preparation only — it is not the enforcement mechanism, and no rule may be written against it.

Displaying the Read more control. The control is rendered only when the body is genuinely clipped — measured from the rendered element (its scroll height exceeding its visible height), re-evaluated whenever the panel is resized. A character count must not be used to decide whether the control appears, or a message that fits inside four lines on a wide screen would still be offered a Read more that expands nothing.

Expansion behaviour.

• Activating Read more expands the message inline — it is not a modal and not a side panel — and the full body is revealed.
• The chat panel keeps its fixed height; the expanded body is read by scrolling inside the panel. The panel does not grow, the Live Broadcast tile beside it does not resize, and no card below the panel is pushed down. A fixed panel edge is also what makes the read less position workable, since that control is anchored to the panel's bottom right.
• One message is expanded at a time. Expanding a second message collapses the first, so several 2,000-character bodies can never occupy the panel at once.
• Once expanded, a read less control appears at the bottom right of the chat window and collapses the message back to its truncated form. It is sticky — it stays visible for the whole expanded state, including while the trader scrolls through the middle of a long body.
• Expanding a message must not trigger the auto-scroll of BR_4.9.1.8. The top of the expanded message holds its on-screen position, even when the feed was anchored at the bottom at the moment of the click.
• Expansion state is bound to the message and survives the arrival of new messages. If the expanded message is purged by the 50-message rolling window (Ref: BR_4.9.1.4), the state is discarded with it — with no warning and no attempt to retain the message.
• Reading a long message is a read affordance, so SIM traders use Read more / read less exactly as LIVE traders do.
• A single message can be up to 2,000 characters (the Discord message limit), which is roughly 30 lines at the panel width — the expanded state must render a body of that length within the scrolling panel.

BR_4.9.1.10: Moderation Is Server-Side Only — No Client-Side UI

Content moderation is executed entirely server-side, through Discord's native AutoMod and the backend Discord bot. There is no client-side profanity filter and no custom moderation layer in the Dashboard.

Blocked before publication. AutoMod evaluates a message before it is posted to the channel, so filtered content never reaches DISCORD_CHAT_STREAM. The Dashboard renders no moderation notice, no redacted placeholder and no "message removed" state — such a message simply never appears in the panel.

Deleted after publication. A message a moderator removes by hand once it is already live has already been broadcast. The stream carries no retract event, so the message stays in the panel until the 50-message window purges it or the broadcast goes offline (Ref: BR_4.9.1.14).

That residual visibility is accepted. No retract event is added to the WebSocket and no withdrawal behaviour is built on the frontend.

BR_4.9.1.11: No Online Count on the Chat Panel — Metric Removed

The chat panel displays no online-member count in any state. The green 38 online pill shown in the wireframe is not built: no badge, no metric, no endpoint, and no polling.

The Discord API exposes no active-viewer count for a specific text channel, so the data does not exist at the required granularity. The panel header carries only the static Live chat label.

• This panel only. The Traders online figure on The PIT card is unaffected — it is a server-wide Discord presence count served by GET /community/server-status and owned by its own UC.

BR_4.9.1.12: Outbound Boundary — Not Owned by This UC

This UC covers the inbound direction only (Discord → Dashboard). The outbound direction (Dashboard → Discord) is unreachable for a SIM account by definition (Ref: BR_4.9.1.1) and is owned by UC_4.14.1 — Discord Chat Stream (TWO-WAY), LIVE.

The following client-confirmed rules belong to that UC and are referenced here only to mark the boundary — they are not restated as behaviour of this panel: the POST /community/chat/send endpoint and its per-user rate limit of 1 request per second; the inline notice Message rate limit reached. Please wait a moment; the 2,000-character maxlength on the input with no custom character counter; Enter to send and Shift+Enter to insert a line break; and the Redis queue plus Batch Worker aggregation that protects the Discord rate limit of 5 messages per 5 seconds per channel.

Note that BR_4.9.1.13 is not an outbound rule: the Host highlight is applied on the inbound render path and is therefore fully in scope for this UC. A SIM trader sees a Host message rendered in gold exactly as a LIVE trader does.

BR_4.9.1.13: Host Highlight — Gold Author Name Driven by the is_host Flag

A message posted by a Host is visually distinguished so that it stands out in the feed.

Definition of Host. Host is a dedicated Discord role, named exactly Host — nothing else. It is explicitly not:

• the creator or owner of the Discord channel;
• an event-management permission set (invite, mute, kick);
• anything the Dashboard computes, stores, or resolves through an extra API call.

Only a small number of accounts hold the role.

Derivation — Discord bot (backend). When the Node.js Discord Bot reads a new message in the broadcast channel, it evaluates the Discord Roles of the message author:

false is the default. The evaluation happens per message, on the backend, before the payload is pushed onto the DISCORD_CHAT_STREAM WebSocket (Ref: BR_4.9.1.5).

Rendering — frontend. The frontend performs no role lookup of its own. It reads the boolean off the incoming payload and applies exactly one of two styles to the author name:

• The styling is binary — there is no third style and no per-role palette. Moderator, Ops, Pod Leader, Associate Trader and every other role render in standard white.
• The highlight applies to the author name only. The message body, the timestamp, and the bubble background are unchanged.
• The style is not inferred from the nickname text. A nickname such as Coach T. in the wireframe renders gold only if that account also holds the Host Discord role; a trader who renames themselves Coach ... on Discord gets no highlight (Ref: BR_4.9.1.6).
• Hydration from the Redis cache carries is_host on each cached message, so the highlight is identical on a re-mounted panel and on live-streamed messages (Ref: BR_4.9.1.4).

Ops config — Stack Trading. The Host role must be created on the Discord server and assigned to the host accounts. Until it exists, every message streams with is_host = false and the feed renders entirely in white — a valid, non-breaking state. Sotatek builds no part of this.

BR_4.9.1.14: Append-Only Feed — Edits and Deletions in Discord Are Not Synchronised

DISCORD_CHAT_STREAM carries exactly one action: append a read-only message to the bottom of the feed. There is no update event and no retract event.

• The backend runs no Discord gateway listener for MESSAGE_UPDATE or MESSAGE_DELETE, keeps no message ID for reconciliation, and never mutates or removes a message already rendered. There is no tombstone, no "edited" marker and no deletion animation.
• The frontend holds a plain append-only list, bounded by the fixed 50-message window (Ref: BR_4.9.1.4).
• Accepted divergence from Discord: a message edited or deleted in Discord after it was broadcast stays on the Dashboard in its original form until the rolling window purges it, or until the broadcast goes offline and the panel clears (Ref: BR_4.9.1.3). This holds for a hand deletion by a moderator mid-broadcast as well (Ref: BR_4.9.1.10).

BR_4.9.1.15: URLs Render as Plain Text — a Security Control

Every URL in the feed renders as plain, non-clickable text, whatever its origin — typed on the Dashboard or fetched from Discord. The frontend treats message_text as a raw sanitised string: no URL regex, no anchor tag, no link preview, no hover card.

This is a security requirement, not a styling choice. A clickable link inside a financial dashboard is a direct path for a bad actor to place a phishing link on a trader's screen. The stream is read-only text; a trader who needs to open a link shared by the community does so in the native Discord application.

Implementation constraint. "Plain text" must be produced by rendering a text node with <, > and & escaped. dangerouslySetInnerHTML — or any equivalent raw-HTML injection — must not be used, or the sanitised string becomes the XSS surface this rule exists to close.

9. Screen Description

Related behaviour owned elsewhere: when the trader navigates into the Community screen, the Newsquawk audio stream in the persistent header switches to Off automatically so that it does not overlap the broadcast audio. That rule is owned by BR_4.1.4.4 and is not restated here.

---

Changelog