Resources

Vision Doc

MRD

Figma file

A new channel type that encrypts message content end‑to‑end and will be available on iOS and Android mobile apps. Desktop App will be supported in future releases but web browsers may never be supported. Some server‑assisted features (threads, presence, typing, reactions, acks, etc.) are enabled via unencrypted metadata; message content remains encrypted. Channel message history is not available for new members and on new devices.

Message content is encrypted. A constrained set of metadata is plaintext to enable real‑time UX and channel management.

Plaintext (server‑visible)

• Channel name

• Thread structure/counters

• Reactions

• Acknowledgements

• Post state/meta: edit/delete/update timestamps, pin state, post type, system props, priority/urgent flag

• Channel/system events: join/leave, rename

• Presence and typing events

• Channel notification setting (All/Nothing) and mute state

Encrypted

• Message content

• File payloads and thumbnails

Client‑side

• Counters may update after decrypt

• E2EE drafts only available locally

E2EE channels live along with other Public and Private channels; identified by shield-lock icon in LHS and Channel Switcher and a red tag in channel/thread headers.

• Sidebar / Home / Find Channels: standard placement. Shield‑lock icon as the identifier.

• Channel header: red “End‑to‑end encrypted” tag with shield-lock icon.

• Channel Info: red “End‑to‑end encrypted” tag with shield-lock icon. No header/purpose.

• Threads list: shield‑lock icon next to channel name

• Thread header: channel name in a red tag with shield-lock icon

Open

One‑time product notice shown when the feature is enabled, once per user (account‑level). Educates and informs the user about E2EE and when to use it.

Trigger & lifetime

• When: First session after E2EE is enabled for the workspace or after user’s first sign‑in to a workspace where it’s enabled.

• Persistence: Show once per user, not per device.

Content (spec text)

• Title: End‑to‑End Encrypted Channels

• Paragraph: “Encrypted channels protect sensitive work by ensuring messages are encrypted on your device and readable only by you. You can use them for confidential discussions, highly secure incident response, and topics that must only stay on user devices.”

• Optional bullets:

  • Message history will not be available for new members or on new devices.

  • End-to-end encrypted channels will only be available in the mobile app.

  • Some features like message search will not be available for encrypted channels.

• Actions: Got it • Learn more

Add End‑to‑End Encrypted Channel to the Type selector. For E2EE, show an info panel in place of purpose/header. Purpose/header are not supported for E2EE channels.

Open

Form Fields

• Type: Public / Private / End‑to‑End Encrypted

• Name: required

• E2EE info panel (for this type only):

  • All messages are end‑to‑end encrypted.

  • Message history will not be available to new members or new devices.

  • Not available on web browsers.

  • Messages will not appear in search results.

  • If your device is removed or reset, access to past encrypted messages may be lost.

After channel is created

• Land in channel; show red header tag and an intro card;

• Help text just above message input box “Messages are end-to-end encrypted”; message input placeholder “Write to <Channel> (encrypted)”.
  
  

  Open

  

   

Permissions

• E2EE type available only if feature is enabled in the system console; user is allowed to create E2EE channel based on the permission scheme (shown below); user is on a supported device.
  
  

  Open

  

You can invite any team member. Those without a supported device are Invited (pending) and get a system DM prompting them to login on a supported device (or update their mobile app). They are shown in a pending state under the Invited section until they login from a supported device. Rekey happens on join.

Open

Add members

• All team members selectable (including those without a registered supported device).

• On confirm:

  • Send system DM to ineligible: “<Inviter> invited you to an end‑to‑end encrypted channel. Please sign in on the Mattermost mobile app or update your mobile app to the latest version to to join and participate in end-to-end encrypted channels.” (+ apps link)
    
    

    Open

    

  • In the Channel Members list, show them under Invited until they sign in from a supported device. Once they do, they should automatically join the channel and move to the members list.

    Open

    

     

Join / First open

• When a new member joins a channel (or an existing member logs in from a new device): no channel history is available; show message separator row with text “Messages sent earlier are not available”
  
  

  Open

  

   

  
  
  

Real‑time UX (presence, typing, thread counts) is supported; content renders after decrypt. Post actions, reactions, threads are gated by decrypt.

Open

Channel view

• Show End-to-end encrypted tag in the channel header and channel info screen.

• Show info-panel with bullet points on E2EE channels in Channel Intro.

Composer

• Show help text just above the message input box: 🔒 Messages are end-to-end encrypted

• Unsupported controls (slash commands, AI, burn-on-read) are hidden

Timeline

• Pre‑join/pre‑device registration history not shown.

• System events (join/leave, rename): shown as regular system messages.

Threads

• In the header, show channel name with the E2EE channel icon as a tag.

• In the threads list, add the E2EE channel icon next to the channel name.

• Show reply counts, participants, read/unread states for decrypted messages.

• Auto‑follow by mention: not available; manual follow/unfollow supported.
  
  

  Open

  

  
  
  

Reactions

• Appear only after decrypt. Then show counts and who reacted.

Post operations (after decrypt)

• Pin, Save/Flag/Star, Mark as unread, Acknowledge.

• Saved E2EE posts: won’t appear in Saved on devices that haven’t decrypted that post.

Composer

• Unsupported controls (slash commands, link preview actions) hidden

Attachments are supported. File metadata like thumbnails should also be encrypted to avoid leaking data.

• Show attachment card (icon + filename + size)

• On tap: decrypt & open preview

Privacy‑preserving, generic push notifications; content rehydrates on decrypt. Channel notifications reduced to two choices.

• Push body: “You have a new encrypted message.”

• Tap to open → fetch + decrypt content.

• Channel notification options: All new messages or Nothing; Mute/Unmute available.

• Mentions/keywords/firstname/channel/all/here/group pings: not supported.

Sessions and registered devices live on one page. Removing a device is explicit and destructive.

Location: Settings → Sessions and Devices

List entry

• Expandable/Collapsible rows per session/device

• Registered for end‑to‑end encryption pill (when applicable)

• Device name, OS, app version, Last activity, First time active, Session ID

• Actions: Logout (ends session; device remains registered), Remove device (red)

Open

Remove device

• Modal with type “remove” to confirm.

• Body: “This will permanently delete all account information, including any end‑to‑end encrypted messages stored on this device. This action cannot be undone.”

• If offline: show Pending removal until next connect.

• Effects: logout, de‑register, stop future delivery; local wipe on next run.

• Feedback: System DM, email confirmation.

Open

A user’s first device will be silently registered for E2EE when they first login from a device that supports E2EE channels after the feature is enabled. Any new device after that must be verified to register for E2EE (so it can send/receive encrypted messages). Verification is voluntary and cancellable; requires access to the first registered device (scan QR). If you don’t have access to the first device, you can remove it and then register the current device.

• Automatically trigger bottom sheet once when the user lands on the home screen after logging in on the second device.

• Gating surfaces (blocking):

  • Opening an E2EE channel on an unregistered device → opens verify device bottom sheet.

  • Attempting to create a new E2EE → opens verify device bottom sheet.

  • Settings → Sessions and Devices shows Verify device (if unregistered).

• Actions: Verify with existing device • I don’t have access to my devices

Open

1. On the new device (unregistered)

   • Tap Verify with existing device

   • Show QR code in a modal with instructions to scan it from a verified device.

   • Success toast: “Device verified for end-to-end encryption.”

   • Failure toast (expired/invalid): “Unable to verify. Please try again.”

Open

2. On the already‑verified device

   • Receive push notification → Verify new device
     OR
     Go to Settings → Sessions and Devices → Verify Device

   • Tapping on the notification opens Scan QR code camera screen

   • Camera sheet scans the QR; show spinner “Verifying device…”

   • Success toast: “Device verified for end-to-end encryption.”

   • Failure toast (expired/invalid): “Unable to verify. Please try again.”

Open

• In Verify this device bottom sheet, link I don’t have access to my devices → Opens modal

• Show devices and inform the user about what they can do.
  “To register this as your primary device, remove your previous encrypted devices first. This will remove all data from your existing device. This action cannot be undone.”

• Action Remove these devices → Confirmation (type‑to‑confirm).

• After removal, this device should automatically be registered and verified as the primary device.

Open

Entry

• User profile bottom sheet → Verify encryption (visible only if the other user has ≥1 supported device).

Open

Modal

• QR code + alphanumeric safety numbers. Either side can scan.

• Device list for the peer: each device shows Verified / Unverified.

  • Tapping on any device gives the option to manually mark it as verified.
    
    

    Open

    

Behavior

• Verification is optional and informational.

• No banners in channels/DMs based on verification state.

• If all devices for a user are verified, show the verified tag in their profile under Encryption.
  
  

  Open

  

Admins enable the feature, control user access, manage devices, and set permissions.

Location: System Console → Plugins → End-to-end Encryption

This page contains all E2EE-related settings:

1. Enable E2EE Channels (toggle)

   1. Disable flow: A confirmation modal will be shown before saving if the admin disables E2EE channels. Existing E2EE channels become read‑only; composer shows “End-to-end encrypted channels have been disabled for this server.”

      • Disabling confirmation modal

        • Title: Disable end-to-end encrypted channels?

        • Body: Disabling will make existing encrypted channels read-only on clients. Users will not be able to send new messages until the feature is re-enabled. Encrypted content already stored on the server will remain encrypted.

        • Buttons: Cancel, Disable (destructive)

2. Section Notice informing the admin how E2EE channels will work and that certain features like legal hold, compliance export, or content auditing won’t be available.

3. User Access Controls (detailed below)

Open

Admins can control which users are allowed to access E2EE channels. This works as a layered permission model—users must both be in the allowed user list AND have the appropriate role permissions (via permission schemes) to create or participate in E2EE channels.

Allow all users (default)

When selected, all users on the server can access E2EE channels (subject to their role permissions).

Allow selected users

When selected, a text input field is revealed where admins can search and select users, LDAP groups, or Teams that’ll be allowed to use E2EE channels. Selected entities appear as removable chips in the field.

Block selected users

When selected, a text input field is revealed where admins can search and select users, LDAP groups, or Teams to block from E2EE access. All other users will have access (subject to their role permissions).

• Clicking the input field and typing triggers an autocomplete dropdown

• Results narrow as the admin types

• Results include users, LDAP groups, and Teams with appropriate icons

• Selecting an item adds a chip to the input

• Chips display the entity name and can be removed via the × icon

When a user loses E2EE access (e.g., removed from an allowed group, added to a blocked list, or their group/team is modified):

• The user is automatically removed from all E2EE channels they are a member of

• The user will no longer see E2EE channels in their sidebar or search results

• The user cannot be invited to E2EE channels until access is restored

Admins should be informed of this behavior via helper text below the access controls: "Users who have access will be able to create and join end-to-end encrypted channels. If access is revoked for a user, they will be removed from all end-to-end encrypted channels."

Open

For servers not on Enterprise Advanced we need to show an upsell card on the End-to-End Encryption page.

Open

Extend existing permission schemes to support E2EE channels.

Open

Admins can view and manage E2EE-registered devices for any user directly from the System Console.

Location: System Console → User Management → Users → [User row] → Actions menu → View user devices

The "View user devices" option appears in the per-user actions dropdown menu alongside existing options (Manage roles, Manage teams, Manage user settings, etc.).

Visibility: This menu item is visible only when:

• E2EE is enabled on the server

• The user has at least one device registered for E2EE

If the user has no registered E2EE devices, the menu item is hidden.

Open

Clicking "View user devices" opens a modal dialog displaying the user's E2EE-registered devices.

• Title: "[User's name]'s registered devices"

• Standard close button (×) in top-right corner

Display devices in a scrollable list.

Open

In System Console > User Management > Channels, E2EE channels should be shown with the E2EE shield icon. We also need to add an option for End-to-end encrypted in the filters on the Channels list.

Open

The option to change the channel type (Public/Private toggle) will not be available for E2EE channels. Regular channels will not be allowed to be converted to E2EE channels.

E2EE is not available on web and desktop app in the MVP; direct routes show a stub with app links.

• Title: Encrypted channels are only available on mobile

• Body: “Use the mobile app to view and send messages in this channel.”

• Actions: Download apps

Open

Quiet failures for decrypt; obvious messaging for history limits; silent rekey.

• New member/device banner: Messages sent earlier will not be available

• Rekey: silent; no UI indicators.

• Verification flow for multiple devices: Will all devices be verified together via the QR code? Should there be a way to manually verify a single device or mark one as verified?

• Do we need a UI state for showing messages/threads/previews in the encrypted state while they are being decrypted?

• Desktop app support

• Cross‑device history (secure backup or cross‑signing).

• Encrypted inline media previews (client‑generated).

• Client‑side search (local index).

• Push notification handling for mention/keyword support.

https://hub.mattermost.com/private-core/pl/j6w6oa7qppddtx1dmuxb1itutc

Updated feature list (18 Nov):
"Should" work without changes:

• Typing indicators

• User status (presence)

• Drafts (mobile)

• Post operations (pin, save, mark as unread, post acknowledgements)

• Threading (follow/unfollow, reply counts, participant list, read state, unread counts, thread replies (not mentions))

• Reactions (adding/removing, reaction counts, who reacted) -- not custom emojis (yet)

• Pinned posts, flag, star (as long as user has msg decrypted locally)

• Channel/system events (join/leave)

• Update channel name

• Channel notifications (only for "All new messages" or "Nothing"), Mute/Unmute

• Archive (does unarchive work on mobile?)

• Leave channel

Planned client-side reimplementation (with work)

• Add/remove channel members

• Push notifications that do not depend on message content

  • we will be able to send a "You have received a new message" push notifications, and we can rehydrate the pushed content after decrypting

• File attachments

• Custom emoji parsing and retrieval (post.metadata.emojis will not be filled out server-side)

List of features that will be unavailable in MVP, but we can reimplement with prioritized engineering effort:

• Channel header, purpose (requires e2ee sync)

• @mentions, custom keyword alerts, firstname mentions, channel/all/here/group pings, mention counts/badges (we can reimplement the client-side notification once we have decrypted the msg, not the push-notification)

• out-of-channel warnings ("@user isn't part of channel, invite them?"), out-of-team warnings

• Hashtag parsing/indexing

• Link/OpenGraph/permalink previews/image preprocessing (incl. automatic embed discovery and unsafe-link protection) -- links will look bare; no inline image cards, no permalink cards

• channel mention rewriting: ~channel -> [~Channel Name](link to channel)

• ldap group mention permissions: @groupname -> highlighted @groupname but only if the author has permissions to mention groups

  • (this will be complicated to reimplement client-side, not sure if cost/benefit is worth it)

• Full-text search:

  • hashtag search over Posts.Message/Hashtags

  • "recent mentions"

  • "jump-to" results as you search

• Server-stored drafts (desktop)

• Post reminders (desktop), e.g., click to "remind me in 30 mins"

• Scheduled posts

• Channel bookmarks

List of features we will never be able to support because it requires the server to have access to the message text:

• The push notifications and desktop/webapp notifications that require @mentions, custom keyword alerts, firstname mentions, channel/all/here/group pings

  • Same restriction for Email notifications

• Priority post notifications

• Persistent post notifications

• Some thread behavior: auto-follow based on mention, mention counters

• Any server-side slash-command parsing and execution (built-in, custom, plugin)

• Outgoing webhooks trigger matching

• Plugin & bot hooks that read/transform messages:

  • plugin hooks

  • moderation/content-flagging

  • MM Agents interactions, messages, rewriting, etc.

• Apps framework

• Slack attachments (they're usually used by webhooks, and can involve interaction with the server -- both of which we can't support in e2ee channels)

• Compliance export

• Auditing (message content)

Features we won't support for e2ee reasons:

• Post: Copy link, copy text

Metadata we are accepting will be sent in the clear:

• Thread structure (root_id, Threads, unread counts)

• Reactions (who reacted, to what message, when)

• Message acknowledgements (who acknowledged, on what post, when)

• Edit/delete/update timestamps, pin state, post type, system props needed for UX

• Post priority/urgent flag

• Channel name
  
  
  
  Feature list (Nov 7)

What we can ship first for feedback (prioritizing time to market):

• Create post

• Edit post

• Delete post

• Favorite/Unfavorite

• Mute/Unmute

• Reply

With work: What we can ship later (will need a "doable" amount of work to E2EE-ify the feature), until then we need to remove them from UI

• Save/Bookmark post

• Reactions

• Mark unread (single device only)

• Push Notifications

  • need to be reworked, scoped to only notify existing E2EE clients

  • cannot be scoped by mentions or thread replies

• Pin/Unpin posts, and viewing those: only if they're already decrypted locally

• Post acknowledgements

• Burn on read (tbd)

• Archive channel

• Drafts (local only)

With a lot of work: Would require significant engineering effort (e.g., new server-side infra, turning server state into client state, etc.), until then we need to remove them from UI

• Search (we would have to develop a new client-side search)

• Saved messages search (client-side search)

• Recent mentions (client-side search)

• Set Channel Header (new server & client code)

• Calls

• File attachments (upload and download)

• Preview file attachments

• File attachment actions

• Share via extension

• Number of unreads

• Msg count

• Mention count

• Scheduled posts

• Drafts (with p2p sync)

• Link previews (fully client-side)

• Playbooks (only with a lot of work)

With a UX decision

• Copy permalink (needs new UX design for receivers)

• Copy channel link (same)

• Copy post text (depends on our security stance -- I vote no)

Not Available: Not possible to do for E2EE channels, either for E2EE/security reasons or for engineering complexity -- need to remove these from the UI

• App bindings (not sure if anyone uses them, but they'll be disabled)

• App binding slash commands/autocomplete (not sure yet how they're used -- tbd)

• Mark as unread

• Ignore Mentions

• Convert public/private

• Follow/Unfollow thread

• Mark thread as unread

• Auto follow threads

• Save thread

• Channel files

• Compliance exports

• Audit logs

• Figma Design File

• Figma Clickable Prototype

• Mobile design spec (if documented separately)

• Jira Ticket

• 1-Pager

Below are some other related links that are supplemental to this feature:

• Future improvement ideas

• Link 2

• Link 3