Overview

Current approach: Opt-in E2EE only for specific channel types, requiring device management, with significant feature trade-offs.

Industry comparison:

• Signal/Wickr/Threema: E2EE by default, zero user action

• Matrix/Element: E2EE by default for private chats since 2020

• Telegram: Opt-in E2EE with clear UX limitations

Critical UX Concerns

Mobile-Only Initial Launch (Stage #1 Scope)

Problem: Stage #1 limits E2EE to "Mobile only (iOS/Android)" with desktop requiring "significant work" in Stage #4. Users cannot access E2EE conversations from their primary work device.

UX Impact:

• Visibility: For Mattermost, desktop/web is the primary platform customers rely on. Launching mobile-only means the vast majority of users won't even see E2EE as an option during their primary workflow.

• Discovery failure: Users who might want E2EE won't know it exists because they're on desktop when making the decision. Desktop users effectively locked out of E2EE features.

• Broken feature perception: Users create E2EE channel on mobile → try to access on desktop → can't read any messages → feel the feature is broken.

• Adoption barrier: Even users who learn about E2EE won't adopt it if they have to switch to their phone for sensitive conversations.

Comparison: Element/Matrix launched with multi-platform support from day one (web, desktop, mobile). Wire launched with web, desktop, and mobile simultaneously. Their security whitepaper explicitly calls out "all platforms" as a requirement for workplace adoption. Wickr, which is Military/government focused, launched with iOS, Android, Windows, macOS, and Linux simultaneously. Their position: tactical users need encryption everywhere. Rocket.Chat launched in beta for web/desktop only, explicitly noting "mobile support was added later."

Solution:

• Do not launch E2EE until desktop support is ready. Reconsider Staging: Move Desktop (Stage 4) earlier in the plan, potentially merging with Stage #1-#2.

• Clearly label the feature as Beta/Under-development until Stage #4/#6.

No Cross-Device Message History Sync

Problem: "E2EE messages can only be read on devices that were registered with their MM server when the message was sent."

UX Impact:

• Does not meet requirements if history is critical for majority use-cases.

• Loss of data is the user loses their device or changes it device without access to the old device

• Creates anxiety about data permanence and device upgrades and makes device switching painful

• Users will screenshot or manually backup important messages (defeating security)

• Particularly problematic in enterprise where device refresh/switching is common

Comparison:

• Element: Solved with encrypted key backup

• Wire: Optional encrypted backup export/import

• Signal: Local device-to-device transfer via QR

Critical: This makes E2EE nearly unusable for real collaboration until Stage #5. People switch devices frequently (laptop↔phone↔tablet).

Solution:

• Move message transfer (Stage #5) into MVP

• Consider any options to implement a simpler approach for history transfer.

  • Users can manually do this with something like: "Set a recovery passphrase to access messages on new devices"

  • Element-style approach: encrypted key backup with user passphrase

• Temporary solution: Until Stage 5, at minimum provide clear UI explaining why messages aren't visible and when the feature will be available

Cannot Enable E2EE on Existing Channels

Problem: "A channel can only be made E2EE when it is first created. E2EE can not be turned off for that channel." Users must create new channels/DMs to use E2EE rather than upgrading existing conversations.

UX Impact:

• High friction: to have secure conversation with existing contacts and groups, must create new DM/channel

• No recovery from wrong initial choice

• Conversation history fragmentation: old messages in old channel, new secure messages in new channel

• Creates decision paralysis ("Will I need this encrypted later?")

• No control for system admins to enforce E2EE for all conversations.

Comparison: Most successful E2EE implementations (Signal, Wire, Wickr) make this decision automatic. Telegram's similar approach where Secret Chats are separate threads is frequently cited as confusing.

Solution:

• Allow one-time upgrade from non-E2EE to E2EE (though acknowledge you can't encrypt past messages)

• Make E2EE default for all DM/GM/Private channels (recommended)

Device Verification Creates Significant User Friction

Problem Statement: Stage 3 requires device key pinning and out-of-band verification. Users see "First E2EE Contact" and "New Device Detected" prompts requiring manual verification (comparing fingerprints, scanning QR codes).

UX Impact

• Interrupts message flow with security prompts

• Requires out-of-band communication (email, call, in-person) to verify

• Many users will skip/dismiss without understanding consequences

• "Verification is encouraged but not required" = most won't do it

• In GMs/Channels, "UX of manual verification becomes unusable"

UX Tradeoffs: Separate E2EE Types vs. Unified Channels with E2EE Toggle

Approach A: Separate DM/Channel Types (Current Mobile-First Plan)

UX Problems

1. DM Duplication & Discovery Confusion

• User has both regular DM and E2EE DM with same person

• Searching for "Alice" returns two conversations - which one to use?

• Left sidebar shows duplicate entries, clutters interface

• Conversation history split across two threads

• "Where did we discuss X?" becomes impossible to answer without checking both

2. Context Switching Overhead

• Want to share sensitive info mid-conversation → must say "switch to E2EE DM"

• Recipient confusion: "Why did you start a new chat with me?"

• Workflow disruption: copy/paste context into new E2EE DM

• Mental overhead tracking which conversation for which topics

3. Channel Management Complexity

• Team has #project-alpha → want secure version → create #project-alpha-secure

• Confusion about which channel to post in

• Need to coordinate team: "Everyone join the E2EE version now"

• Old channel lingers with partial history

• Permission management duplicated across both channels

4. Platform-Specific Type Lock-In

• E2EE DM type created on mobile might not work properly when desktop launches (Stage 4)

• Potential migration/conversion needed later

• Technical debt: maintaining two parallel DM/Channel systems

• Different codepaths = different bugs, harder maintenance

Benefits

• Clear visual distinction (separate entries in sidebar)

• No risk of accidentally converting important channels

• Can have different feature sets without explaining gaps

Approach B: Option to enable E2EE for Channels and DMs

UX Benefits

1. Single Conversation Per Contact/Topic

• One DM with Alice, regardless of security mode

• Search returns one conversation with all history

• No duplication in sidebar

• Clear conversation timeline (even if encryption status changes mid-conversation)

2. Natural Workflow

• No context switching or new conversation creation

• History preserved in single thread

• Visual indicator shows where E2EE begins (timeline marker)

• Security as property of conversation, not identity of conversation

3. Scalability

• When desktop launches, no migration needed

• Same conversation accessible across platforms

• E2EE capability just enables/disables based on client support

• Future-proof architecture

4. Industry Precedent

• Element/Matrix: E2EE is property of room, can be enabled at creation or upgraded

• Signal/Wire: Everything is E2EE, no decision needed

• WhatsApp: All chats E2EE by default, users never think about types

Implementation Challenges

1. Retroactive Encryption Impossible

• Old messages remain unencrypted when E2EE enabled

• Need clear visual distinction in timeline

• User education: "Messages from this point forward are E2EE"

• Risk: users misunderstand and think old messages are now secure

2. Feature Availability Toggle

• When E2EE enabled, some features stop working (bots, webhooks, search)

• Need clear explanation of what changes

• Users might enable E2EE without understanding tradeoffs

• Requires good warning UI: "Enabling E2EE will disable: ..."

3. Mixed Device Support (Mobile-First Launch)

• If mobile launches first with unified approach, desktop users can't participate in E2EE channels hence making it unusable

• Solution: delay launch until multi-platform ready

4. Accidental Enabling

• Easy to accidentally toggle E2EE on important channel

• Need confirmation dialog with clear warnings

• Risk of user confusion if they don't understand what they enabled

Resources

• Figma Design File

• Vision document

• MRD