## Remote Support Chat Architecture Decision (Dec 2025) ### Context Adding chat to remote support sessions required decisions on: 1. Data model 2. Real-time transport for unauthenticated guests 3. Message persistence ### Decisions Made 1. **Model**: Session-scoped `SupportSessionMessage` model (not reusing `ChatRoom`/`ChatMessage`) - Each `SupportSession` has_many `:support_session_messages` - Messages have `participant_type` enum (operator/guest) since guests have no User record - `user_id` nullable (null for guest messages) 2. **Guest Real-time Transport**: ActionCable (WebSocket) - Guests cannot use NATS (no device authentication) - ActionCable authenticates via guest_link_token in connection params - Channel: `SupportSessionChatChannel` streams from `support_session_chat:{session_id}` 3. **Persistence**: All messages persisted for audit/review - Viewable after session ends - Chat history section in SessionDetailComponent 4. **UI**: Collapsible panel alongside video - Same `SessionChatPanel` component for both operator and guest - Operator uses NATS, guest uses ActionCable (abstracted via hook) ### Related Tickets Epic #100: Add Chat to Remote Support Sessions - #101: SupportSessionMessage model - #102: ActionCable channel - #103: SendChatMessageService - #104: API endpoints - #105: SessionChatPanel component - #106: Operator integration - #107: Guest integration - #108: Chat history review