UX Spec: Burn-on-read messages

Project Plan | Figma file | WIP Figma Prototype

Burn-on-Read (BoR) messages are a special type of message that delete themselves after the recipient has read them, following a short countdown period. Unlike standard messages, a BoR message is initially concealed in the channel and must be actively revealed by the recipient; once revealed, its content is visible only briefly before being automatically erased for that user. This feature enhances security by ensuring sensitive messages exist only temporarily once viewed.

Key Features

Per‑message control: Allow a sender to mark a single message as Burn‑on‑Read (BoR) from the composer.
Admin‑governed duration: One server‑wide BoR duration configured in System Console (default 10 minutes) with allowed range 1 minute to 8 hours. Duration is not editable at a per-user level.
Mask until reveal: Recipients see a masked placeholder and must click/tap to fetch and reveal content. Countdown starts on the recipient’s first view.
Per‑recipient burn: Message content is deleted for that recipient when their timer expires or if they choose Burn now.
Enterprise‑safe behavior: No replies, threads, forwards, quick‑copy text on BoR content. Email/push notification should contain placeholder only.

Not in scope

Channel‑level disappearing messages (Phase 2) or any kind of maximum time-to-live for BoR messages.
Any other security features like end‑to‑end encryption.
Ability for users to change duration that a BoR message will be viewable.

Admin Configuration (System Console)

System Administrators can control the availability and behavior of Burn-on-Read messages through System Console settings (under Site Configuration > Posts). The following admin options are provided:

Enable Burn-on-Read Messages: Boolean toggle (Default: Off). – This enables or disables the BoR messaging feature for the server. When enabled (True), the Burn-on-Read option will appear in the message input box for users who are permitted to use it, and those users can send BoR messages. When disabled (False), the Burn-on-Read option does not appear in the UI at all.
Burn-on-Read Duration: Dropdown (presets) (Default: 10 minutes). – This setting defines the countdown duration for Burn-on-Read messages once they are revealed.
- Administrators can choose from preset values (1 minute, 5 minutes, 10 minutes, 30 minutes, 1 hour, 8hours) or select “Custom” to input a specific duration. If a custom duration is set, it can be specified in minutes (or hours) up to a maximum of 8 hours. This duration is used by all BoR messages across the system: once a recipient reveals a BoR message, that timer dictates when the message will delete for that user. Important: Changing this setting affects newly sent messages going forward; it does not retroactively change the timer for messages already sent.
Users Allowed to Send Burn-on-Read Messages: User/Team/Group selection list (Default: All Users). – This setting restricts which users are permitted to use the Burn-on-Read feature. By default, it is set to “All Users,” meaning any user can mark messages as BoR. An admin can limit this to specific individuals, teams, or user groups. This granular control allows scenarios such as enabling BoR only for certain departments, security roles, or specific teams as needed.
Maximum time to live for burn-on-read messages: Dropdown (presets) (Default: 7 days). – This setting defines the maximum time before a burn-on-read message will be deleted for all recipients and the sender after it is sent.

Reorganizing Posts page into sections

As a part of this effort, we should reorganize the Posts page into logical sections to make it easy to consume and understand for admins.

For servers not on the Enterprise-Advanced license, we should show a Enterprised advanced label on this section for Self-deleting messages. If the feature is not available, the section can show a feature discovery state as shown below.

First-Time User Experience

Upon first introducing the BoR feature to a user, the interface will highlight the new capability with a guided tour popover. On desktop/web, a small pulsating dot indicator is shown on the flame icon in the message composer to draw attention. When the user clicks the pulsating dot, a tour point popover appears, anchored to the BoR icon. This popover contains a brief description of Burn-on-Read messages and a demonstration GIF. The tour popover is presented only once per user to introduce the feature. After the first-time use, the pulsating indicator and popover will not reappear, so as not to disturb the user’s regular workflow.

Sending a Burn-on-Read Message

When the feature is enabled, users composing a message have the option to mark it as a Burn-on-Read message.

Web/Desktop – Composing & Sending

The message input box includes a new control to activate Burn-on-Read mode for a message:

Burn-on-Read Icon Button: A “🔥” icon is added to the message input box right next to the Message Priority icon.
- The icon’s tooltip on hover reads “Burn-on-Read message” with a sub-text “Message will be deleted for a recipient 10 minutes after they open it.”
Activating Burn-on-Read Mode: Clicking the flame icon toggles Burn-on-Read mode for the current draft message. Once BoR mode is activated for a draft message, an indicator tag (similar to the “Important”/“Urgent” priority labels) will appear in the compose area to confirm this. Note: There is no ‘toggled’ state for the BoR icon, however, clicking on it icon again would turn BoR off.
Composer Indication: Once Burn-on-Read mode is active, a visible tag “Burn on read (10m)” is shown in the message input box. This tag denotes that the message being typed will self-destruct 10 minutes after being read. An “x” icon next to the tag (on hover) allows the sender to cancel Burn-on-Read mode (reverting the message to a normal message).

Combining with Priority: The BoR setting works independently of message priority flags. A message can be marked as Burn-on-Read and marked Important/Urgent at the same time. In such cases, the message input box will display both indicators (e.g. an “Urgent” tag and the “Burn-on-Read” tag), and the sent message will carry both properties. There is no conflict; both features apply simultaneously.
Message Content: All standard message features (file attachments, emoji, formatting) are available while in Burn-on-Read mode. If the user attaches files or images, those attachments will also be treated as message content, subject to the same deletion timeline.
Sending the Message:
- To the sender (the author): the message appears immediately in the channel with its content visible. It is labeled with the Burn-on-Read icon (flame) next to the timestamp, indicating its BoR nature. The sender does not need to click to reveal their own message.
  - Hovering on the BoR flame icon should show a tooltip informing the user when the message will be deleted. It should also show information about how many people have read the message so that the sender can understand why they can still see the message.
- To recipients (other users in the channel): the message initially appears in a concealed state – the content is not visible. Instead of text or attachments, recipients see blurred content, along with the flame icon is shown next to the message timestamp (reinforcing that this message is BoR). The message is effectively unreadable until the recipient takes action to reveal it.

Constraints and Edge Cases

Message actions: Burn-on-Read messages still support basic interactions while they exist, apart from any action that can potentially leak the contents of the message. Specifically, Forwarding and Copy Text options will not be available for BoR messages. Recipients can react with emoji to a burn-on-read message during the time it’s visible to them. Reactions will disappear along with the message (and will not be retained after deletion).
Mark as unread: Marking a message as unread will not stop the timer or return the message to the masked state. Once revealed, a burn-on-read message cannot be returned to the concealed state. Marking as unread can still be allowed to allow users to use the unread channel indicator and AI features that are triggered from the New Messages separator line.
Editing: Once sent, Burn-on-Read messages cannot be edited by the sender. The option to edit (normally available via message menu for regular posts) is removed for ephemeral messages. This is because editing can create an inconsistency if some recipients have seen one version and others another.
Thread replies: It is also not possible to send a thread reply to a BoR message and the reply option is hidden from the message actions menu. This also means that the Follow thread option would not make sense for BoR messages and would be hidden.
Deleting (Manual): The sender can manually delete a burn-on-read message before its auto-deletion, just as they could with a normal message. Doing so immediately removes it for all users.
Draft Persistence: If a user toggles Burn-on-Read on and types a message but then navigates away (e.g., goes to another app) before sending, the draft (including its BoR state) should persist when they return, just like normal drafts.
Permalink previews: There should be no permalink previews shown for BoR messages.

Receiving & Reading a Burn-on-Read Message

When a Burn-on-Read message arrives for recipients, the content is not shown immediately. Instead, recipients see a concealed message placeholder and must click on it to reveal the content.

Concealed Placeholder: In the channel view (desktop, web, and mobile), a BoR message initially appears as a concealed block. Hovering on it will show a tooltip “Click to Reveal”. The actual content (message text or attachments) is only fetched when the user clicks on the message.
Revealing the Message: When a recipient clicks or taps the concealed message placeholder, the message content is revealed to that recipient only. The actual message text (and any attachments or images included) will appear in place of the placeholder for that user. At the moment of reveal, the system starts a Burn-on-Read countdown timer for that recipient. Other recipients who have not yet revealed the message will still see the concealed placeholder in their own view – each recipient controls their own reveal moment and subsequent timer. Revealing is an explicit action; there is no “auto-reveal.” If a user never clicks the placeholder, the message remains concealed (and un-deleted) in their view.

Alternate design option

We can show a more standard block of color with help text to reveal the message.

Post-Reveal Countdown and Deletion Behavior

Once a recipient reveals a Burn-on-Read message, a countdown timer begins for that user. The message will automatically delete itself for that user when the timer expires.

The following describes the timer UI and deletion sequence for both recipients and the sender:

Timer Chip Display: Upon reveal, a timer chip is shown next to the message timestamp. This is a tag containing a flame icon and the remaining time on the BoR countdown (e.g. “10:00” for 10 minutes).
Countdown Behavior and Visual Warning: The timer chip appears in a subtle red error style with a burn icon and a countdown timer. If the user navigates away from the channel, the timer will not be paused.

Manual Early Deletion : Recipients have the option to delete the message from their view immediately, without waiting for the timer. The timer chip itself acts as a “burn now” control. On desktop, clicking the timer chip will trigger a confirmation modal to instantly remove that message for the current user. Hovering over the chip on desktop shows a tooltip (“Deletes in XX:XX. Click to delete now.”) to communicate this functionality. On mobile, the timer chip on mobile will be tappable just like on desktop – tapping it will show a confirmation modal to delete the message for that user. We will also add the delete option in the message actions menu since tapping on the chip might not be obvious.
Auto-Deletion: If the user does not manually delete the message, it will be automatically removed from that user’s view when the countdown reaches zero. The removal is permanent for that user – the message post disappears entirely from the channel view without any residual marker. This deletion is also propagated to all of that user’s active sessions/devices.
Effect on Pinned/Saved Posts: Users are allowed to pin a BoR message in the channel or save a BoR message while it is visible (during the view window). However, doing so does not prevent the message from being deleted on schedule. If a user pinned the message, the moment the message “burns” (is deleted for that user), it will also disappear from the channel’s pinned posts list for that user. Similarly, if the user saved the message to their Saved list, it will be removed from Saved items after it deletes.

Sender’s Message Lifecycle

The sender of a Burn-on-Read message has a slightly different lifecycle for the message in their own view:

Visible Until All Recipients Read: When the sender posts a BoR message, they immediately see their own message content in the channel (since they wrote it). The sender’s copy of the message will not begin its deletion countdown until all intended recipients have revealed the message. In other words, the sender’s auto-delete timer is deferred. The sender retains a visible copy of the message as long as at least one recipient has not yet read (revealed) it. This allows the sender to reference what was sent in case recipients ask about it or respond.
Indicator for Unread Recipients: While the BoR message is pending (not yet revealed by everyone), the sender’s view provides an indication of that status. The flame icon on the sender’s message will show a tooltip on hover: “Not read by X people” (with X being the number of recipients who have not revealed it). This gives the sender awareness of how many people still haven’t opened the message. [Optional] On mobile, we can show this information in the message actions menu.
Sender’s Timer Start: Once all intended recipients have revealed the message, the system will trigger the sender’s own countdown timer. At that moment, the sender’s UI will display the same timer chip (flame icon with countdown) on their copy of the message, and the timer begins using the standard duration (e.g. 10 minutes). The chip for the sender behaves exactly as it does for recipients: it counts down, turns red in the last minute, and the sender can click/tap it to delete the message immediately. If the sender takes no action, their message will auto-delete when their timer expires. Essentially, the sender’s message “burns” only after everyone else has had a chance to read it, ensuring no one misses the content (unless the sender manually deletes it earlier).
Edge Case – Unrevealed Messages: If a Burn-on-Read message is never revealed by one or more recipients (for example, a user is inactive for an extended period of time), then in this Phase 1 implementation there is no automatic deletion event based on time alone for unopened BoR messages. The message will remain in a concealed state indefinitely for any recipient who never opens it, and it will likewise remain visible to the sender (since not all recipients have read it). (Phase 2 will introduce a maximum time-to-live for unopened messages, but that is out of scope for Phase 1 – see Future Considerations.) Note that the sender still has the option to manually delete the message at any time.

Notifications and Alerts

For Burn-on-Read messages, notifications are handled in a privacy-preserving manner. Any out-of-channel alert (such as push notifications on mobile or email notifications) must not reveal the content of a BoR message. Instead, notifications will use a generic description to avoid “pre-reading” the message. Specifically:

Push Notifications: When a BoR message is sent and push notifications are triggered for a recipient, the push notification will not include the message text. Instead, the notification body will say: “<Sender Name> sent you a message in <Channel Name>.” (For example: “Alice sent you a message in Town Square.”) The user would need to open the app and reveal the message to read its content.
Email Notifications: Similarly, if email notifications are enabled and a BoR message triggers an email alert (e.g., for mentions or direct messages), the email should not contain the message content. Instead, it will contain a placeholder line such as: “<Sender Name> sent you a message in <Channel Name>.”
In-app notifications: In-app desktop/mobile notifications should also exclude the message text for BoR messages.

What if users join/leave channels with BoR messages?

Scenario: BoR message is sent —> Read by 5 of 50 users in the channel.

New user joins the channel:
- Since the new user can access history, and the BoR message is still a a part of the channel, they should see the BoR message in the concealed state. They can click on it to reveal it.
- The number of total recipients in the sender's tooltip increases to 51 (to match the number of channel members) and the message only get's wiped when the new member also reveals the message.
Known issue: The new user might not know they need to scroll up and reveal the BoR message.
Existing member leaves the channel without revealing the message:
- The message should get deleted from the channel and database when all the remaining (49) members have revealed and read the message.
- The number of total recipients in the sender's tooltip decreases to 49 to match the number of channel members.
Existing member leaves the channel after revealing the message:
- The count of the number of members who have read the message shown in the Sender’s tooltip will still count the users who have left the channel.
- The message should get deleted from the channel when the remaining members have also revealed and read it.
- The number of total recipients in the sender's tooltip decreases to 49 to match the number of channel members.
  Known issues:
  - The total number of recipients shown to the sender will be inaccurate and can lead to some ambiguity:
    - When everyone has read the message, the senders tooltip might show ambiguous info like Read by 50 of 49 recipients,
    - When just one person is remaining to read the message, the senders tooltip would show Read by 49 of 49 recipients but the message won’t be deleted yet as there’s 1 more person remaining who’s not read the message.

Additional Considerations

Excluded from Search: Burn-on-Read messages are not indexed in search. They will not appear in search results. This prevents transient message content from lingering via search. Once a BoR message is gone (for a user or entirely), it should not be discoverable through the search function.
Database Backups: If a Burn-on-Read message exists in the database at the time of a database backup, it will be included in that backup (as it was still present in the system at that moment). However, once a BoR message has been deleted for all recipients (i.e., it has burned for everyone or was manually deleted), it is removed from the database. Future backups will not contain that message.
Compliance Export: BoR messages should not be included in compliance exports.
Content Flagging for BoR Messages: Users can flag a Burn-on-Read message during the view window (while the content is visible to them). Flagging a BoR message follows the standard content moderation flow: the message is removed from the channel for all users according to the system’s content flagging rules (it might immediately disappear pending review, similar to how other flagged content is handled). Importantly, if a BoR message is flagged, the system preserves the message content in the Content Reviewer’s report view so that reviewers can access it even after it would normally expire.
- Restoring Flagged Messages: If a flagged BoR message is reviewed and restored by a reviewer, it will reappear in the channel only for recipients who had not yet revealed it. Those users will see the concealed placeholder back in their view, with the ability to reveal it as originally intended (and the standard BoR timer will start upon reveal). Recipients who had already revealed the message before it was flagged will not see the content reappear automatically, since their viewing event already occurred.

This presents an edge case where some users who already revealed a message might not have had sufficient time to read it. We can consider restoring the message with only the remaining timer but that’s NOT a must-have if technically complex. We can weigh the value/effort ration for this.

Screenshot and Copying Limitations: The Burn-on-Read feature adds some restrictions within the Mattermost application, but it cannot prevent users from capturing the content by other means. Recipients may still take screenshots, photos, or copy the content manually during the time the message is visible.

Future Considerations (Post-Phase 1)

This specification covers the Phase 1 implementation of Burn-on-Read messages. There are additional features and safeguards planned for future phases, which are not included in this initial rollout:

Channel-Level Ephemeral Settings: Future enhancements will allow enabling disappearing message functionality on a per-channel basis (for all messages in that channel). This goes beyond the current feature, which works at a per-message level. BoR is a per-message option chosen by the sender, not a default for any channel. Any channel-level ephemeral messaging controls will be handled separately in the future and are out of scope for now.
Maximum Time-to-Live for Unread Messages: In a later phase, we can to introduce a global expiration for BoR messages that remain unread. For example, an admin might set a maximum lifespan (e.g. 7 days) after which a Burn-on-Read message will be deleted even if some recipients never opened it. This would prevent BoR messages from lingering indefinitely in channels. In Phase 1, there is no maximum TTL for an unread BoR message – it can remain concealed indefinitely until read.