Cookiemonsters

Imported from the pre-Redmine CookieMonsters TODO during the 2026-08-29 migration.

Original priority: P1 — Community experience and polish

• Build the signed-in People / messaging experience as a persistent right-side rail:
  • show Online members first and Offline members below;
  • add Online status visibility under User Settings with clear per-viewer privacy modes:
    • Show to everyone — normal presence behaviour;
    • Hide from everyone — nobody else sees that the member is currently online;
    • Hide from everyone except Friends — accepted friends can see the real online/offline state, while non-friends cannot;
    • hiding online status should not remove the member from Members, communities or other places where that viewer is otherwise allowed to see them; it only hides live presence and should make the member appear offline/hidden rather than exposing the real state;
    • when presence is hidden from a viewer, also avoid leaking equivalent last active / last seen information that would defeat the setting;
    • apply the setting consistently to the People rail, Members cards/lists, member/profile presence indicators, community member lists, search/discovery surfaces and presence APIs;
    • enforce presence privacy server-side per viewer, not only by hiding the green dot in the frontend;
    • changes should take effect immediately without requiring logout/login and should not emit activity/notifications that reveal the hidden member is online;
    • block rules remain stronger than presence settings and continue to make blocked members unable to discover the blocker at all.
  • later prioritize sections as Friends → My communities → Site;
  • use Site as the label for the overall CookieMonsters site scope instead of “CookieMonsters community” when that label appears in UI;
  • clicking a member opens a direct chat without leaving the current page;
  • make the member identity in an open chat a real profile shortcut: clicking the other member's avatar in the chat header (top-left beside their name/status) should open that member's normal profile / Wall destination, where the viewer can see all profile information, Wall/News Feed posts, Gallery, games/connections and other sections they are currently authorized to discover; the chat must not expose anything beyond the same profile/privacy/block/NSFW rules that apply when opening the member normally;
  • keep the avatar visibly/cursor-accessibly clickable on desktop and touch-friendly on mobile, with an accessible label such as Open {name}'s profile; opening the profile may use the normal page route and does not need to keep the chat floating above it unless we later deliberately add that behaviour;
  • add a small Chat settings icon beside the existing + attachment control at the bottom of the chat composer; keep it compact and recognizable (e.g. sliders/gear) so the composer does not become crowded;
  • clicking Chat settings opens a soft compact panel for settings specific to that conversation, including a clear History: On / Off summary/control that maps to the conversation history-retention system below rather than creating a second independent history feature; if richer retention is enabled, show the actual current mode (e.g. Always, 24 hours, No history) instead of reducing it to a misleading boolean;
  • include a Chat background picker in Chat settings with an initial curated set of 9 soft, cute CookieMonsters backgrounds; they should be subtle enough that message text/bubbles remain easy to read and should include at least one warm hearts design plus other cozy choices such as soft clouds, stars/moon, cookies, gentle flowers, pastel gaming shapes, tiny sparkles and calm abstract gradients;
  • backgrounds are presentation only and must never change message/history/privacy behaviour; store the chosen background as the current member's preference for that conversation so each participant may choose their own background independently; provide a neutral/default option and make changing it immediate with a small preview grid;
  • useful additional per-chat settings should include Mute notifications, Message sound on/off, a shortcut to that conversation's Auto translate override/target when translation exists, and later a compact Privacy & security row showing E2EE/session verification state; avoid duplicating global User Settings unless a per-chat override is genuinely useful;
  • keep Chat settings visually playful but restrained: no dense admin form, use short rows/toggles and a 3×3 visual background grid, and make all settings usable on mobile without covering the entire conversation unnecessarily;
  • direct messages are persistent backend data, so messages sent while a member is offline act as an inbox and appear when they return;
  • show unread counts and mark conversations read server-side;
  • HIGH PRIORITY — open chats at the member's catch-up point instead of the beginning of the conversation:
    • when a conversation is opened from Messages, the envelope/unread alert, People rail or another normal entry point, do not start at the oldest/first message and force the member to scroll through the full history;
    • if unread messages exist, position the conversation around the boundary between the last message the member had already read and the first unread message, so the member gets a small amount of context and then sees all new messages in their real chronological order;
    • render a clear but soft divider such as Catch up / New messages immediately before the first unread message; keep the last previously-read message visible just above it where practical so the transition makes sense;
    • if there are no unread messages, open at the latest/end of the conversation rather than at message #1;
    • if a conversation is new and has never been read, treat the first available message as the first unread message and show the catch-up divider appropriately without inventing a fake previous-read state;
    • persist the per-member/per-conversation last-read message/position server-side so the same catch-up point works across devices and reconnects, and only advance it when the member has actually viewed/read the relevant messages;
    • loading older history above the catch-up point should happen on demand/infinite-scroll without moving the user's current reading position unexpectedly;
    • after the member reaches/reads the new messages, update unread counts and the stored read boundary consistently without reordering messages or jumping the scroll position.
  • add a small message/envelope icon in the signed-in UI that lights up/pulses when unread messages exist and the relevant chat is not currently open;
  • show a subtle unread badge/count on the envelope and update/clear it as messages are read;
  • clicking the envelope should open unread conversation(s) or the message inbox without forcing a full page change;
  • HIGH PRIORITY — add a privacy-safe incoming chat alert so a new direct message is immediately noticeable without exposing the private conversation on screen;
    • play a short, pleasant message pling when a new chat message arrives, unless the member has muted chat sounds or the platform/browser prevents audio;
    • show one clear in-site popup/toast such as You have a new message and update the message/envelope unread state at the same time;
    • the privacy-safe default must not show the message body, attached image/GIF thumbnail or other private content in the popup; the actual message is revealed only after the member deliberately clicks/opens the conversation;
    • default to a generic notification that does not need to reveal the sender either; under User Settings, allow an explicit privacy preference such as Generic only, Show sender name, and later Show message preview, with content preview always opt-in rather than the default;
    • clicking the popup/envelope should open the relevant conversation and only then render/decrypt the message content according to normal chat permissions/E2EE rules;
    • avoid notification spam and duplicates: if several messages arrive quickly in the same unopened conversation, keep one clear active popup/alert and increment the unread count rather than stacking many copies of the same warning;
    • if that exact conversation is already open and visibly focused, do not show a redundant privacy popup; a subtle sound/unread update may still follow the member's preferences;
    • make sound, popup visibility and preview level configurable under User Settings, but keep a clearly visible generic new-message alert as the recommended/default behaviour;
    • browser/PWA push notifications should follow the same privacy-first rule when CookieMonsters is backgrounded: default to generic New message / New encrypted message and reveal no plaintext or attachment preview unless the member has explicitly opted into a safe supported preview mode;
    • unread/delivery state remains server-side so the alert is reliable across reconnects, while notification display must respect blocks, conversation deletion, history expiry and future group-chat rules.
  • add push notifications for new messages when CookieMonsters is installed/added as a mobile web app/PWA and the member has granted notification permission;
  • use a service worker/Web Push style flow so notifications can arrive even when CookieMonsters is not open in the foreground;
  • tapping a push notification should open CookieMonsters directly to the relevant conversation;
  • avoid duplicate/noisy alerts: if that conversation is already open and visible, do not also trigger the envelope pulse/push unnecessarily;
  • add notification preferences under User Settings later so members can control push/sound behaviour while unread state inside the site remains reliable;
  • support multiple parallel conversations and evolve the existing conversation/member/message model into multi-member group chat without replacing the data model;
  • add chat attachments and richer composer controls:
    • emoji picker;
    • activate the GIF picker/search as a real chat feature now; replace/remove the current Coming later placeholder instead of leaving GIF sending deferred;
    • GIF search/selection should insert the chosen GIF into the current conversation composer and send it as normal chat content with the same delivery, delete-for-everyone, history-expiry, blocking and privacy-notification rules as other attachments;
    • + attachment button for uploading photos;
    • support normal clipboard paste directly into the focused chat composer: pasted text behaves like normal typed text, pasted URLs stay in the message/link flow, and pasted/copied images/screenshots are captured as pending chat attachments without requiring the + button;
    • show a preview of pasted image attachment(s) before send and let the sender remove a mistaken pasted item before sending;
    • pasted images must use the exact same protected attachment pipeline as manually uploaded photos, including authorization, E2EE attachment handling when enabled, Masked, View once/timers, Delete for everyone and chat-history expiry; clipboard paste must never become a shortcut around media permissions/security;
    • preserve uploaded photo originals while rendering compact previews in chat;
    • clicking an attached image should open a larger in-site view rather than forcing users out of CookieMonsters;
  • add opt-in Auto translate for chat so members can comfortably talk across languages:
    • provide Auto translate incoming messages to: [language] under User Settings as the account-level default for messages the member receives;
    • include German / Deutsch 🇩🇪 as a normal translation target alongside the other CookieMonsters site languages;
    • present the CookieMonsters site languages as friendly quick-pick choices using flag + language name for fast recognition, while never relying on a flag alone to represent a language;
    • add a searchable language picker so a member can type/search for another supported language even when it is not one of the site's normal UI languages;
    • if the member already has a preferred/site language, offer that as the sensible default incoming-translation target while still allowing any supported target language to be selected;
    • automatically detect the incoming message language; if it differs from the chosen target language, show the translated text by default;
    • always keep the original message available behind a small Show original / Show translation control so meaning can be checked when a translation seems wrong;
    • do not unnecessarily re-translate messages already written in the member's chosen target language;
    • add a separate optional Auto translate what I write to: [language] setting for outgoing messages, so a member may write naturally in their own language and have CookieMonsters also prepare a translation into English, German or any other selected supported language for the recipient;
    • outgoing translation must be opt-in and independently configurable from incoming translation; a member may use incoming-only, outgoing-only, both, or neither;
    • when outgoing auto-translation is enabled, preserve the sender's original wording and let the recipient switch between Original and Translated rather than replacing the author's text destructively;
    • the recipient should see the prepared translated version directly when it matches their needs, while still being able to apply their own incoming Auto translate preference if they want a different language;
    • allow account defaults plus a per-chat override later, including different incoming/outgoing target languages for a specific conversation;
    • translation should make two-way multilingual chat feel natural: e.g. one person can write only Italian while another reads German, and replies can be written in German while the Italian-speaking member receives Italian automatically;
    • for E2EE chats, incoming translation must happen after decryption on the recipient's trusted device, and outgoing translation must happen on the sender's trusted device before the encrypted message/translation variants are sent; CookieMonsters must never need plaintext on the server to provide translation;
    • prefer an on-device/local translation model or another design that keeps plaintext inside the E2EE boundary; if a third-party translation service is ever offered, it must require explicit opt-in and clearly explain that decrypted text would be sent to that provider;
    • never store translated plaintext server-side for E2EE conversations; original and any prepared translation variants must remain inside the encrypted payload, and local cached translations must respect Edit, Delete for everyone, View once and chat-history expiry;
  • add message editing and delete-for-everyone semantics:
    • members can edit text messages they themselves sent; the edited version should update for every participant and show a subtle Edited marker;
    • edits must be represented as authenticated conversation events so another client/device cannot forge an edit to somebody else's message;
    • members can delete text messages they themselves sent, but CookieMonsters must have no “Delete for me” option for sent chat content: choosing Delete always means Delete for everyone;
    • deleting a message should replace/remove it for every participant and make the original message body unavailable according to the server-side retention/cleanup model;
    • members can likewise delete images/attachments they themselves sent, and deletion always means Delete for everyone;
    • deleting an image must revoke access to the underlying protected attachment, thumbnail and preview for all participants and remove the stored media according to cleanup policy, not merely remove the chat bubble;
    • deletion events must propagate to offline clients when they reconnect so an old local conversation view cannot simply re-fetch deleted content from CookieMonsters;
    • clearly distinguish an edited message from a deleted message without keeping the deleted plaintext visible in normal UI;
  • design end-to-end encrypted (E2EE) one-to-one chat sessions so even the CookieMonsters server/site administrator cannot read private message or attachment contents:
    • plaintext message text and private attachment decryption keys should exist only on the participating members' trusted devices; the server stores/transports ciphertext plus the minimum metadata required for delivery, unread state, expiry and routing;
    • do not invent custom cryptography: use a well-reviewed established protocol/library design suitable for asynchronous messaging, forward secrecy and key rotation (for example a Signal-style identity/session + ratcheting model or another audited equivalent);
    • create per-device identity keys and session keys so a member can use more than one trusted device without sharing a single raw long-lived conversation key everywhere;
    • adding/removing a trusted device must trigger the appropriate key distribution/rotation behaviour, and the UI should make meaningful device/security changes visible to the participants;
    • provide a way to verify a one-to-one encrypted session/device identity later, e.g. safety number/QR-style verification, without making normal chatting cumbersome;
    • encrypt image/file attachments client-side with per-attachment keys before upload; the server must only store encrypted attachment bytes and must not possess the key needed to decrypt them;
    • E2EE must work together with Edit, Delete for everyone, masked images, View once/timers and chat-history retention by sending authenticated encrypted control/events between participants while the server enforces only the ciphertext/metadata lifecycle it is allowed to know;
    • Delete for everyone cannot mathematically erase a copy a recipient already saved, screenshotted or extracted from a compromised/offline device; CookieMonsters should remove its server ciphertext/media and instruct all trusted clients to remove the item, but the UI must not promise impossible remote erasure outside CookieMonsters;
    • with E2EE enabled, server-side auto-translation/full-text inspection is impossible by design; incoming/outgoing translation must follow the trusted-device Auto translate rules above and remain inside the encrypted boundary;
    • push notifications for E2EE chats should default to a generic privacy-safe notice such as New encrypted message unless we later implement a sound encrypted-preview design that still keeps plaintext away from the server/push provider;
    • server-side search/indexing of plaintext is not available for E2EE chats; any message search must be local/on-device or use a privacy-preserving design chosen later;
    • moderation/admins must not have a hidden master key or silent decrypt path; if a participant reports abusive encrypted content, reporting can explicitly let that participant submit selected decrypted message(s)/attachments as evidence to moderators;
    • define secure key backup/recovery before launch: account/password recovery must not quietly give CookieMonsters a universal decryption key; if recovery of encrypted history is supported, it needs an explicit end-to-end encrypted recovery design;
    • begin with 1-to-1 E2EE sessions; design group-chat encryption separately rather than weakening the one-to-one model for convenience;
  • add masked/private image sending for chat attachments:
    • when attaching an image, let the sender optionally mark it Masked so the image itself is hidden/covered in the conversation until the recipient actively clicks/taps to reveal it;
    • the masked placeholder must not leak a readable thumbnail/preview before reveal;
    • masking is available for normal persistent images too, not only disappearing images;
    • every image with a display timer is always masked automatically and the sender cannot disable masking for timed images;
  • add per-image display timers with the initial choices View once, 1 minute, 2 minutes, 5 minutes, 10 minutes, plus normal/no timer:
    • timers should begin when the recipient first reveals/opens the image, not merely when it is sent;
    • View once means one reveal session: after the recipient has opened it and then leaves/closes/scrolls away from that revealed image, it becomes unavailable and cannot simply be opened again;
    • for 1/2/5/10-minute images, keep the image available only until the chosen time has elapsed after first reveal, then replace it with a clear expired placeholder;
    • expired/view-once state must be enforced server-side for both the attachment record and protected image bytes, not merely hidden with frontend CSS/JS;
    • delete or make the underlying timed attachment irretrievable according to the server-side cleanup policy so copied URLs cannot bypass expiry;
  • add a conversation-level history retention mode that either participant can set for the whole chat, with clear visible state for both sides:
    • No history;
    • Keep history for 1 hour;
    • Keep history for 2 hours;
    • Keep history for 5 hours;
    • Keep history for 24 hours;
    • Always keep history;
    • history retention applies to chat messages and normal attachments created while that mode is active; define the exact behaviour for already-existing older history before launch rather than silently deleting unexpected content;
    • No history should make new chat content intentionally non-persistent and purge it server-side after the minimum delivery/view state needed for the conversation to function;
    • timed/view-once content keeps its own stricter expiry even if the conversation history is set to a longer period or Always; the shortest applicable retention wins;
    • changing history mode must be obvious to both participants with a small system message/state indicator so nobody unknowingly believes a chat is permanent when it is not;
    • server-side scheduled cleanup must remove expired message bodies and attachment files/previews/thumbnails consistently, not merely hide them in the UI;
  • keep all masking, expiry, editing/deletion, encryption, translation and history-retention behaviour compatible with protected-media authorization, blocking and future group chats.

CM-TODO-ID:c6f53d65ae6a25a28793

Future notes, acceptance criteria and status changes belong in this Redmine issue.