| 1 | // Message-content typing. The `type` rides *inside* the encrypted payload (the |
| 2 | // server only ever sees ciphertext), so it's an end-to-end signal between |
| 3 | // clients, never server metadata. Everything is a "chat" message today; tagging |
| 4 | // them now lets future clients introduce other payload kinds (system notices, |
| 5 | // presence, …) and lets each client decide which kinds it will render. |
| 6 | |
| 7 | // The type this client stamps on every message it sends. |
| 8 | export const MESSAGE_TYPE_CHAT = "chat"; |
| 9 | |
| 10 | // A transient "is typing" presence hint. It rides its own WebSocket frame |
| 11 | // (never stored, never pushed) and is consumed before reaching the feed, so it's |
| 12 | // deliberately kept out of ACCEPTED_TYPES below — it must never render as a |
| 13 | // message even if one ever reached the render path. |
| 14 | export const MESSAGE_TYPE_TYPING = "typing"; |
| 15 | |
| 16 | // The types this client will render. A null/absent type is a legacy message |
| 17 | // from before payloads were tagged, so it's treated as a chat. Narrowing this |
| 18 | // set — or dropping the null allowance — is how we get "more limited" later. |
| 19 | const ACCEPTED_TYPES = new Set([MESSAGE_TYPE_CHAT]); |
| 20 | |
| 21 | // acceptsMessageType reports whether a decrypted payload of the given type |
| 22 | // should be rendered. `null`/`undefined` (a legacy, untyped payload) is allowed. |
| 23 | export function acceptsMessageType(type) { |
| 24 | return type == null || ACCEPTED_TYPES.has(type); |
| 25 | } |
| 26 | |
amadan