// Message-content typing. The `type` rides *inside* the encrypted payload (the
// server only ever sees ciphertext), so it's an end-to-end signal between
// clients, never server metadata. Everything is a "chat" message today; tagging
// them now lets future clients introduce other payload kinds (system notices,
// presence, …) and lets each client decide which kinds it will render.

// The type this client stamps on every message it sends.
export const MESSAGE_TYPE_CHAT = "chat";

// A transient "is typing" presence hint. It rides its own WebSocket frame
// (never stored, never pushed) and is consumed before reaching the feed, so it's
// deliberately kept out of ACCEPTED_TYPES below — it must never render as a
// message even if one ever reached the render path.
export const MESSAGE_TYPE_TYPING = "typing";

// The types this client will render. A null/absent type is a legacy message
// from before payloads were tagged, so it's treated as a chat. Narrowing this
// set — or dropping the null allowance — is how we get "more limited" later.
const ACCEPTED_TYPES = new Set([MESSAGE_TYPE_CHAT]);

// acceptsMessageType reports whether a decrypted payload of the given type
// should be rendered. `null`/`undefined` (a legacy, untyped payload) is allowed.
export function acceptsMessageType(type) {
  return type == null || ACCEPTED_TYPES.has(type);
}