Umbra

Private, Peer-to-Peer Messaging with End-to-End Encryption

Technical Whitepaper

Version 1.0 — February 2026

1. Executive Summary

Umbra is a cross-platform, end-to-end encrypted messaging platform built on a zero-trust architecture. Unlike conventional messaging applications that rely on centralized servers to process and store messages, Umbra ensures that all message content is encrypted on the user's device before transmission, making it cryptographically impossible for relay servers, network operators, or any third party to access message content.

Core Principle

Messages are encrypted client-side using industry-standard cryptography. Relay servers handle only opaque ciphertext — they never see plaintext content, metadata, or encryption keys.

256-bit
AES-GCM Encryption
6
Supported Platforms
0
Plaintext on Servers

Key Differentiators

2. The Problem: Privacy in Modern Messaging

2.1 Centralized Trust Models

Traditional messaging platforms operate on a centralized trust model where users must trust the service provider with their communications. Even platforms claiming "end-to-end encryption" often retain significant metadata, require phone number registration, or implement server-side key escrow mechanisms.

2.2 Key Vulnerabilities in Existing Solutions

Vulnerability Impact Affected Platforms
Phone number requirements Identity linkage, SIM swap attacks Signal, WhatsApp, Telegram
Centralized key servers Single point of compromise Most E2E platforms
Metadata collection Social graph analysis, timing attacks Nearly all platforms
Closed-source clients Unverifiable security claims WhatsApp, iMessage
Cloud backup vulnerabilities Unencrypted message exposure WhatsApp, iMessage

2.3 The Metadata Problem

Even with strong message encryption, metadata — who communicates with whom, when, and how often — reveals sensitive information. Research has demonstrated that metadata analysis can reveal personal relationships, political affiliations, medical conditions, and more. Traditional messaging platforms collect and retain this metadata indefinitely.

Metadata Exposure

"We kill people based on metadata." — Former NSA Director Michael Hayden, 2014

3. The Solution: Umbra Platform Overview

Umbra addresses these fundamental privacy challenges through a combination of cryptographic innovation and architectural design decisions that minimize trust requirements.

End-to-End Encryption

All messages encrypted with X25519 key exchange and AES-256-GCM before leaving the device. Keys never transmitted to servers.

Decentralized Identity

Self-sovereign identity using DID:key method. No registration, no phone numbers, no email addresses required.

Peer-to-Peer Messaging

Direct WebRTC connections between peers. Relay servers used only for signaling and offline message queuing.

Zero-Knowledge Relays

Relay servers handle encrypted blobs only. No access to message content, sender/recipient relationships, or encryption keys.

Offline Messaging

Encrypted messages queued for offline recipients with 7-day TTL. Delivered automatically when recipient reconnects.

Cross-Platform

Native applications for iOS, Android, macOS, Windows, Linux, and web browsers. Single codebase via React Native + Rust.

3.1 Trust Minimization

Umbra's architecture is designed to minimize the trust users must place in any single entity:

4. Technical Architecture

4.1 System Components

CLIENT APPLICATIONS SERVICE LAYER CORE LAYER (Rust/WASM) RELAY INFRASTRUCTURE iOS Android Web macOS Windows Linux @umbra/service TypeScript API Layer @umbra/wasm WASM Bridge @umbra/plugin-* Plugin System Cryptography Ed25519 · X25519 AES-GCM · HKDF Identity DID:key · BIP-39 Profile Management Storage Encrypted SQLite sql.js (WASM) Network libp2p · WebRTC Relay Client relay.umbra.chat US East · WebSocket Signaling seoul.relay.umbra.chat Asia Pacific · Federation Mesh

Figure 1: Umbra System Architecture — Four-layer design from client applications to relay infrastructure

4.2 Technology Stack

Layer Technology Purpose
Frontend React Native + Expo Cross-platform UI (iOS, Android, Web)
Desktop Tauri (Rust) Native desktop shell (macOS, Windows, Linux)
Core Rust + WebAssembly Cryptography, networking, storage
Networking libp2p + WebRTC P2P connections, NAT traversal
Database SQLite / sql.js Encrypted local storage
Relay Rust + Axum WebSocket signaling server

4.3 Relay Server Architecture

Relay servers provide three core functions while maintaining zero knowledge of message content:

  1. Signaling Relay — Forwards WebRTC SDP offers/answers and ICE candidates for peer connection establishment.
  2. Offline Message Queue — Stores encrypted message blobs for offline recipients (7-day TTL, 1000 messages per user).
  3. Session Relay — Enables QR code-based friend adding without requiring both parties to be online simultaneously.
Federation

Multiple relay servers can form a federation mesh, enabling geographic distribution and redundancy. Users on different relays can communicate seamlessly — the federation protocol routes messages automatically.

5. Cryptographic Security Model

5.1 Cryptographic Primitives

Umbra employs a carefully selected set of cryptographic primitives, all implemented using audited, pure-Rust libraries from the dalek-cryptography and RustCrypto projects:

Algorithm Standard Purpose Security Level
Ed25519 RFC 8032 Digital signatures 128-bit
X25519 RFC 7748 Key exchange (ECDH) 128-bit
AES-256-GCM NIST SP 800-38D Authenticated encryption 256-bit
HKDF-SHA256 RFC 5869 Key derivation 256-bit
PBKDF2-SHA512 RFC 8018 Seed derivation 256-bit
SHA-512 FIPS 180-4 Hashing 256-bit

5.2 Key Hierarchy

Recovery Phrase BIP-39 · 24 words · 256 bits entropy PBKDF2-SHA512 (2048 rounds) Master Seed 256 bits HKDF-SHA256 with domain separation Signing Key Ed25519 • Identity • Message Signatures • DID:key Generation • libp2p PeerId Encryption Key X25519 • Key Exchange • E2E Encryption • Shared Secrets • Per-Conversation Keys Storage Key AES-256 • Database Encryption • Local Key Storage • Message Archive • Contact Data

Figure 2: Key Hierarchy — From recovery phrase to derived purpose-specific keys

5.3 Message Encryption Protocol

Each message is encrypted using the following protocol:

  1. Shared Secret Computation — X25519 ECDH between sender's private key and recipient's public key produces a 32-byte shared secret.
  2. Key Derivation — HKDF-SHA256 derives the encryption key using the shared secret, conversation ID as salt, and domain string "umbra-message-encryption-v1".
  3. Encryption — AES-256-GCM encrypts the message with:
    • 256-bit derived key
    • 96-bit random nonce (unique per message)
    • Additional Authenticated Data (AAD): sender_did || recipient_did || timestamp
  4. Signature — Ed25519 signature over the ciphertext and metadata ensures authenticity.
Security Properties

5.4 Decentralized Identifiers (DIDs)

Umbra uses the DID:key method for self-certifying identifiers:

did:key:z6MkhaXgBZDvotDUGRy7K9L7M2yvCpREH5eXtbA8vwFRNbfH

The DID encodes the user's Ed25519 public key directly, enabling:

6. Platform Features

6.1 Messaging

1:1 Direct Messages

End-to-end encrypted conversations between two users. Messages encrypted with unique per-conversation keys derived via HKDF.

Group Chats

Encrypted group conversations with shared group keys. Key rotation on member changes ensures forward secrecy.

Offline Messaging

Encrypted messages queued on relay servers for offline recipients. 7-day retention with automatic delivery on reconnection.

Read Receipts

Optional encrypted delivery and read confirmations. Recipients control whether to send receipts.

6.2 Voice & Video Calling

Umbra supports encrypted 1:1 voice and video calls using WebRTC:

6.3 Communities

Large-scale community support with Discord-like features:

6.4 Identity & Social

Self-Sovereign Identity

24-word BIP-39 recovery phrase. No phone numbers or email addresses. Full identity portability across devices.

QR Code Friend Adding

Single-scan friend requests via relay-assisted sessions. Works even when one party is offline.

Contact Management

Friend requests, blocking, and contact nicknames. All contact data encrypted locally.

Multi-Device

Restore identity on any device using recovery phrase. Message history synced via encrypted relay.

6.5 Unlimited File Sharing

Umbra's P2P architecture enables unrestricted file sharing that competitors cannot match:

Capability Umbra Competitors
File Size Limit (Desktop) Unlimited 100MB–2GB
File Size Limit (Web) 2GB 25MB–100MB
Transfer Method Direct P2P Server upload/download
Storage Location Your device Their servers
Encryption Per-file E2E Varies
Sender 256KB Chunks WebRTC DataChannel Direct P2P (No server) Recipient Reassemble & Verify Relay Server Fallback Encrypted chunks only, 24h cache If NAT blocked

Figure 3: P2P File Transfer — Direct WebRTC with relay fallback for NAT-blocked peers

Technical Implementation

User Benefits

6.6 Plugin & Extension Ecosystem

Umbra's plugin system enables community-driven growth while maintaining security through sandboxed execution:

PLUGIN SANDBOX Plugin Code • Custom commands • UI components • Bot automations • Message handlers • Themes • Integrations Controlled API Access Plugin API usePluginAPI() usePluginStorage() useSlotProps() PluginPanel Messages, friends KV + SQL storage UI integration Custom panels

Figure 4: Plugin Architecture — Sandboxed execution with controlled API access

Why This Matters for Users

Traditional Platforms Umbra
Features controlled by corporation Features built by community
Updates when company decides Plugins update independently
Limited customization Unlimited customization
Vendor abandonment kills features Community maintains plugins
Community-Driven Benefits

6.7 How Plugins Fuel Platform Growth

Traditional platforms grow based on corporate roadmaps and investor demands. Umbra grows based on what users actually want:

Traditional Platform Growth Investors Executives Feature Roadmap Users get what company decides Umbra Community Growth Gamers Developers Activists Build Plugins for their needs Everyone benefits from shared plugins

Figure 5: Platform Growth Models — Corporate-driven vs Community-driven

Real Examples of Community-Driven Features

Community Need Plugin Solution On Traditional Platforms
Gaming group wants voice channel push-to-talk Community builds PTT plugin in days Wait years for roadmap, if ever
Journalists need secure file drop Build SecureDrop integration plugin Not profitable, never built
Developers want GitHub notifications GitHub webhook plugin available Pay for enterprise tier
Community wants custom emoji reactions Emoji pack plugins, unlimited Limited to paid tiers
Activists need message auto-delete Ephemeral message plugin Conflicts with data harvesting

6.8 How Other Platforms Monetize Your Data

When a service is free, you are the product. Here's how major platforms and their partners profit from your private communications:

The Data Harvesting Pipeline

Your Data Messages, contacts location, behavior Platform WhatsApp, Discord Telegram, Slack Stores everything on their servers Data Brokers Acxiom, Oracle, Experian Sell to anyone Analytics Firms Palantir, Cambridge Analytica Build profiles on you Advertisers Google, Meta, Microsoft Target you everywhere Used Against You • Insurance pricing • Employment screening • Political manipulation

Figure 6: How your messaging data flows to third parties who profit from it

Documented Cases of Data Exploitation

Company What They Did Scale Source
Cambridge Analytica + Facebook Harvested user data to build psychological profiles, used for political manipulation in 2016 US election and Brexit 87 million users NY Times, FTC $5B Fine
Palantir + Various Aggregates data from social platforms to build surveillance profiles for governments and corporations Billions of records Vice, The Intercept
Meta/WhatsApp Shares metadata (who you talk to, when, how often) with Facebook for ad targeting despite "E2E encryption" 2+ billion users ProPublica, EFF Analysis
Discord Scans all messages, sells behavioral data to advertisers, shares with law enforcement without warrant 150+ million users Discord Privacy Policy, Transparency Report
Slack Enterprise customers can read all employee DMs. AI trained on customer conversations without consent. 20+ million users Slack Discovery, Wired
Telegram Non-E2E by default. Stores all messages on servers. Has complied with authoritarian government requests. 700+ million users EFF, Reuters
Clearview AI Scraped billions of photos from social/messaging platforms to build facial recognition database sold to police 30+ billion images NY Times, ACLU Settlement

Why This Is Impossible on Umbra

Architectural Impossibility — Not Just Policy

Other platforms promise not to exploit your data. Umbra makes it technically impossible:

Attack Vector Other Platforms Umbra
Read message content Stored in plaintext or with keys they control E2E encrypted — servers see only ciphertext
Build social graph Know all your contacts and who you message P2P connections — relays don't know who talks to whom
Track message timing Full timestamp logs of all activity Direct P2P — no centralized timing data
Link real identity Phone/email required, linked to real identity No registration — cryptographic identity only
Sell to data brokers Business model depends on it No data to sell — we don't have it
Comply with mass surveillance Can provide everything to government Cannot comply — data doesn't exist on servers
Train AI on conversations Your chats train their models Conversations never leave your device

6.9 Security Breaches That Cannot Happen on Umbra

Centralized platforms are honeypots for attackers. Here are real breaches that are architecturally impossible on Umbra:

Major Messaging Platform Breaches

Incident Platform Impact Source Why Impossible on Umbra
WhatsApp Pegasus Exploit (2019) WhatsApp Zero-click spyware via call. Journalists, activists targeted. Guardian, Citizen Lab No phone numbers = no phone-based attacks
Discord Data Breach (2023) Discord User data exposed via compromised support agent. Discord Blog, BleepingComputer No support agents have access — E2E encrypted
Slack Security Incident (2022) Slack Private code repositories and tokens exposed. Slack Blog, SecurityWeek No API tokens to steal — P2P architecture
Telegram Phone Leak (2020) Telegram 42 million Iranian user phone numbers exposed. Comparitech, ZDNet No phone numbers ever collected
Facebook Audio Transcription (2019) Messenger Contractors transcribed private voice messages. Bloomberg, The Verge Voice P2P with DTLS-SRTP — no server recording
Signal Twilio Breach (2022) Signal 1,900 phone numbers exposed via Twilio phishing. Signal Blog, TechCrunch No phone-based registration — no third-party SMS
Microsoft Teams Token Flaw (2023) Teams Auth tokens stored in plaintext, full account access. Vectra Research, Dark Reading No central auth server — cryptographic identity
Zoom Bombing (2020) Zoom Predictable meeting IDs, mass harassment. FBI Warning, NY Times Cryptographic handshakes required — no guessable IDs

Classes of Attacks Eliminated by Architecture

Server-Side Breaches

Eliminated. No message content, contacts, or metadata stored on servers. Hackers breach relay → get encrypted blobs, useless without keys.

Insider Threats

Eliminated. No employees can access user data because no user data exists on our infrastructure. Zero trust architecture.

SIM Swap Attacks

Eliminated. No phone numbers involved. Identity is a cryptographic key pair, not a phone number that can be hijacked.

Credential Stuffing

Eliminated. No passwords or usernames. Your 24-word recovery phrase is your identity — never transmitted, never stored remotely.

Mass Surveillance

Eliminated. Even with a warrant, we cannot provide message content. Cryptographic design, not policy promises.

Supply Chain Attacks

Minimized. Open source code is auditable. No third-party SMS, email, or identity providers in the authentication chain.

The Fundamental Difference

Other platforms say "trust us with your data." Umbra says "we cannot access your data even if we wanted to." This isn't policy — it's mathematics. The encryption keys exist only on your device.

6.10 Network Effects: More Users = Stronger Network

Unlike traditional platforms where more users means more server costs and infrastructure burden, Umbra's P2P architecture means every new user strengthens the entire network.

The P2P Scaling Advantage

Traditional Platform Scaling Central Server More users = More server load More cost = Higher prices or more ads Umbra P2P Scaling More users = More connection paths Faster transfers = Stronger network

Figure 7: Scaling comparison — Centralized bottleneck vs P2P mesh strengthening

How User Growth Reduces Infrastructure Dependency

Network Size Direct P2P Success Rate Relay Usage Boost Node Dependency
Early Stage (1K users) ~40% High — most messages via relay High — files cached on boost nodes
Growing (100K users) ~65% Medium — relay for offline/NAT Medium — popular files P2P cached
Mature (1M+ users) ~85% Low — relay mainly for signaling Low — DHT provides file discovery
Scale (10M+ users) ~95% Minimal — direct connections dominate Minimal — peers serve each other
The Virtuous Cycle

More users → More peers online → Higher chance of direct connection → Faster transfers → Better experience → More users join → Network gets even stronger

What Happens as the Network Grows

File Transfers Get Faster

With more peers, files are cached across more devices. Popular files can be downloaded from nearby peers instead of distant relays. Swarm downloads from multiple peers simultaneously.

Messages Deliver Instantly

More users online = higher chance your recipient is reachable directly. P2P connections have lower latency than relay-routed messages. Real-time feels truly real-time.

Offline Resilience Improves

Messages can be held by mutual friends until recipient comes online. Multiple paths to reach any user. Network routes around failures automatically.

Infrastructure Costs Drop

Less relay bandwidth needed as P2P takes over. Community boost nodes share the load. The network becomes self-sustaining rather than dependent on central infrastructure.

6.11 Boost Nodes: Community-Powered Infrastructure

Boost nodes are community-operated servers that enhance network performance without compromising privacy. They're the bridge between full P2P and traditional infrastructure.

How Boost Nodes Work

User Device Uploads file (encrypted chunks) Cache Boost Node Community-operated Encrypted storage High availability DHT participant Recipient A Downloads fast Recipient B Gets later Recipient C Different timezone Direct P2P when both online Boost Node sees: • Encrypted blobs • No keys • No metadata

Figure 8: Boost nodes cache encrypted content for faster delivery to offline recipients

Boost Node Capabilities

Function How It Works Privacy Guarantee
File Caching Stores encrypted file chunks for community members. Serves files when original uploader is offline. Only encrypted chunks stored. No keys, no filenames, no metadata.
DHT Bootstrap Acts as entry point to the distributed hash table. Helps new peers discover content and other peers. Sees DHT queries but not content. Like DNS — knows you're looking, not what you find.
Relay Fallback Routes messages when direct P2P fails due to NAT. Maintains connection through firewalls. Encrypted envelope only. Cannot read content or determine relationships.
Offline Queuing Holds encrypted messages for offline community members. Delivers when they reconnect. Time-limited storage. Auto-deletes after delivery or TTL expiry.

Who Runs Boost Nodes?

Community Admins

Large communities can run dedicated boost nodes for their members. Faster file sharing within the community. Full control over retention policies.

Privacy Advocates

Organizations and individuals who believe in private communication can contribute infrastructure. Similar to Tor relay operators.

Power Users

Users with always-on servers or NAS devices can run boost nodes to help the network and improve their own connectivity.

Official Umbra Nodes

Bootstrap nodes operated to ensure network availability during early growth. Designed to become less necessary over time.

Zero Trust by Design

Even if a boost node operator is malicious, they gain nothing. All content is encrypted before reaching the boost node. No keys are ever transmitted. The worst a rogue operator can do is delete data — they cannot read it.

6.12 Communities: Encrypted Spaces for Groups

Umbra Communities bring the best of Discord and Slack to a privacy-first platform. Large groups can collaborate with channels, roles, and permissions — all end-to-end encrypted.

Community Architecture

Umbra Community Spaces (Categories) # general Text channel # announcements Read-only 🔊 voice-chat Voice channel 📁 files File channel # dev-talk Text channel # support Text channel Roles 👑 Admin 🛡️ Moderator ✓ Verified Member Encryption Group key per community Key rotation on member changes Admins cannot read DMs Server sees nothing

Figure 9: Community structure — Spaces, channels, roles, and encryption layers

Community Features

Feature Description Privacy Implementation
Spaces Organize channels into categories (like Discord categories). Collapse/expand for navigation. Space metadata encrypted. Relay sees only encrypted community blob.
Text Channels Persistent chat rooms. Thread support for focused discussions. Emoji reactions. All messages E2E encrypted with community group key.
Voice Channels Real-time voice chat with push-to-talk or voice activation. Screen sharing. WebRTC P2P with DTLS-SRTP. Audio never touches servers unencrypted.
File Channels Dedicated channels for file sharing. Folder organization. Version history. Per-file encryption keys. Chunked P2P transfer. Boost node caching.
Roles & Permissions Custom roles with granular permissions. Channel-specific overrides. Role hierarchy. Permission data encrypted. Role assignments visible only to members.
Moderation Tools Mute, ban, warning system. Audit logs for admins. Slow mode. Auto-mod via plugins. Mod actions encrypted. No external visibility. Community self-governs.

How Communities Stay Private

Group Key Encryption

Each community has a shared group key. Messages encrypted with this key. Key rotates when members leave, ensuring departed members can't read new messages.

Invite-Only Access

Communities are not discoverable publicly. Access only via invite links shared by members. Links can be time-limited or single-use.

Admin Limitations

Admins can manage channels and roles but cannot read members' DMs. Even community admins don't have backdoor access to private conversations.

Distributed State

Community state synced via encrypted events through relays. No central server holds the authoritative copy. Members' devices collectively maintain state.

Communities vs Traditional Platforms

Aspect Discord/Slack Umbra Communities
Message Storage All messages on company servers, readable by employees E2E encrypted, stored on member devices only
File Sharing Files uploaded to CDN, scanned, stored indefinitely P2P transfer, encrypted chunks, member-controlled
Voice Calls Routed through company servers, potentially recorded P2P WebRTC, DTLS-SRTP encrypted, never on servers
Member Data Email, IP, activity logs collected and monetized Cryptographic identity only, no PII required
Compliance Requests Can hand over all community data to authorities Nothing to hand over — data doesn't exist on servers
Platform Ban Risk Entire community can be deleted by platform decision No central authority can delete your community
Your Community, Your Rules

Traditional platforms can ban entire communities overnight based on opaque "terms of service" decisions. With Umbra, your community exists on members' devices — no corporation can delete it, censor it, or hold it hostage.

6.13 Honest Assessment: Potential Challenges

Transparency is a core value. While we believe Umbra offers significant advantages, we also acknowledge the challenges and tradeoffs of our approach:

Technical Challenges

Challenge Impact How We're Addressing It
NAT Traversal Complexity Some users behind strict firewalls may struggle with direct P2P connections Relay fallback ensures messages always deliver. TURN servers for voice/video. Ongoing WebRTC improvements.
Offline Message Delivery If both peers are rarely online simultaneously, messages may be delayed Relay queuing with 7-day TTL. Boost nodes extend availability. Push notifications when messages waiting.
Device Storage Requirements Messages stored locally means your device needs sufficient storage Configurable retention policies. Smart cleanup suggestions. Storage manager with one-click optimization.
Recovery Phrase Responsibility Lose your 24 words = lose your identity forever. No "forgot password" option. Clear onboarding warnings. Multiple backup prompts. Future: social recovery via trusted contacts.
Early Network Size P2P benefits increase with more users. Early adopters may rely more on relays. Strategic boost node placement. Geographic relay distribution. Network strengthens as it grows.

Adoption Challenges

Challenge Reality Our Approach
Network Effect Barrier Messaging apps are only useful if your contacts use them too Focus on community use cases where groups migrate together. Easy invite links. Cross-platform support.
Convenience vs Privacy Tradeoff Phone number login is familiar. Recovery phrases require more responsibility. Make UX as smooth as possible. Progressive disclosure of complexity. Don't sacrifice privacy for convenience.
Feature Parity Gap Established platforms have years of feature development Plugin ecosystem lets community add features. Focus on core experience first. Open development.
Trust in New Platform Why trust a new platform over established ones? 100% open source. Auditable cryptography. Actions speak louder — we architecturally cannot access your data.

Known Limitations

Web Browser Limits

Web version has 2GB file size limit due to browser memory constraints. Desktop app has no limits. We encourage power users to use native apps.

No Account Recovery

By design, we cannot recover your account. Your recovery phrase is the only key. We're exploring social recovery options for future releases.

Moderation Complexity

Decentralization means no platform-level moderation. Communities must self-moderate. This is a feature for privacy, but requires active community management.

Resource Usage

P2P connections and local encryption use more device resources than server-based apps. Modern devices handle this well, but older hardware may notice impact.

Why We're Transparent About This

Every platform has tradeoffs. We believe the privacy and ownership benefits of Umbra's architecture far outweigh these challenges. But we respect users enough to be honest about what we're building and what we're still improving. We'd rather under-promise and over-deliver than hide limitations behind marketing speak.

7. Comparison with Existing Solutions

Privacy & Security

Feature Umbra Signal WhatsApp Telegram Discord Slack Matrix
E2E Encryption (Default)
No Phone/Email Required
Self-Sovereign Identity
Zero-Knowledge Servers
No Metadata Collection
Open Source (Full Stack)

Architecture & Ownership

Feature Umbra Signal WhatsApp Telegram Discord Slack Matrix
Decentralized/P2P
Direct Peer Connections
Self-Hosted Option
Federated Relays
Recovery Without Server
Account Portability

File Sharing Capabilities

Feature Umbra Signal WhatsApp Telegram Discord Slack Matrix
Max File Size (Desktop) 100MB 2GB 2GB 500MB 1GB 100MB
Max File Size (Mobile) 2GB 100MB 100MB 2GB 25MB 1GB 100MB
P2P File Transfer
Per-File Encryption
Resume Interrupted Transfers
Files Stay on Your Device

Features & Extensibility

Feature Umbra Signal WhatsApp Telegram Discord Slack Matrix
Communities/Servers
Voice/Video Calls
Plugin/Bot Ecosystem
Community-Maintained Plugins
Sandboxed Plugin Execution
Custom Themes
Native Desktop Apps

Business Model & Trust

Aspect Umbra Signal WhatsApp Telegram Discord Slack Matrix
Revenue Model Open Source Donations Meta/Ads Premium Nitro/Ads Subscription Foundation
Data Monetization
Corporate Parent None Foundation Meta Private Public Co Salesforce Foundation
Shutdown Risk Low Medium Low Medium Medium Low Low

✓ = Full support · ◐ = Partial/Limited · ✗ = Not supported · ∞ = Unlimited

7.1 Key Advantages

Why Choose Umbra?

7.2 User-Facing Benefits Enabled by Architecture

Umbra's technical architecture directly translates to tangible user benefits:

Data Sovereignty

What You Get How Architecture Enables It
Your data stays on your devices P2P messaging + local-first storage
No account to be banned/deleted Self-sovereign identity via recovery phrase
Export all data anytime Open database format + no server dependency
Works without internet Offline-first design with sync on reconnect

Future-Proof Platform

Traditional Risk Umbra Solution
Company shuts down → lose everything P2P + local storage → data persists
Platform pivots → features removed Plugin ecosystem → community maintains
Price increases → pay or leave Open source → run your own relay
Terms change → accept or lose access Self-sovereign → identity is yours forever

Real-World Scenarios

Journalist Protecting Sources

No phone number links identity. Messages never touch corporate servers. Share large document archives directly. Recovery phrase = portable secure identity.

Remote Team Collaboration

Share unlimited file sizes (video, design files, datasets). Community spaces with channels and roles. Plugin integrations for workflows. No per-seat licensing.

Privacy-Conscious Individuals

Same features as mainstream apps. No advertising, no data mining. No social graph analysis possible. Full control over digital identity.

Developer Communities

Build custom plugins for your community. Share code repositories without size limits. Integrate with development workflows via SDK. Open-source everything.

8. Conclusion

Umbra represents a fundamental rethinking of how private messaging platforms should be built. By combining:

Umbra delivers a messaging platform that does not compromise between privacy and usability. Users enjoy the features they expect from modern messaging — group chats, communities, voice/video calls, unlimited file sharing — while maintaining cryptographic guarantees that their communications remain private.

The Architecture Ensures
Get Started

Visit umbra.chat to try Umbra in your browser, or download native apps from GitHub Releases.

Further Reading

Resource Link
Source Code github.com/InfamousVague/Umbra
RFC 8032 (Ed25519) datatracker.ietf.org/doc/html/rfc8032
RFC 7748 (X25519) datatracker.ietf.org/doc/html/rfc7748
NIST SP 800-38D (AES-GCM) csrc.nist.gov/publications/detail/sp/800-38d/final
RFC 5869 (HKDF) datatracker.ietf.org/doc/html/rfc5869
BIP-39 Specification github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
W3C DID:key Method w3c-ccg.github.io/did-method-key