Separate ChatMessage — space-level chat is not unified under ChatRoom

Space-level chat (messages in a chat Space) uses a standalone ChatMessage model with a direct FK to Space, not an embedded ChatRoom. Circle.so treats space-level chat as a ChatRoom with parent_type=Space — a single ChatRoom model for every kind of conversation. We chose not to follow that.

Considered Options

• Unified ChatRoom: Delete ChatMessage, add parent(FK) -> Space to ChatRoom, migrate all existing data, update every view, WebSocket consumer, and headless endpoint to point at ChatRoomMessage instead. Closer to Circle.so's model, less total models.
• Separate ChatMessage (chosen): Keep ChatMessage as-is for space-level chat. ChatRoom/ChatRoomMessage remains the DM and group-chat system. Two tables, two sets of views and consumers, no shared logic between them.

Why separate was chosen

The ChatMessage system was implemented first and the ChatRoom system was added later for headless API compatibility. By the time ChatRoom existed, ChatMessage had views, WebSocket consumers, tests, and frontend integration in place. The migration cost was high for zero user-facing benefit — members don't care if their chat messages live in the same table as their DMs.

Consequences

• Any new chat feature must be built against ChatRoom/ChatRoomMessage; ChatMessage is legacy-equivalent. New chat spaces are still served by ChatMessage — there is no documented plan to migrate them.
• Developers have to remember which model to use for which context: ChatMessage for space chat, ChatRoomMessage for DMs and group chats. The two have different capabilities (ChatMessage: no rich text, no threading; ChatRoomMessage: rich text, threading, soft-delete).