IA Watson
IA Watson SecureP
ML-KEM-1024
HopChat - MessageSecure

IA Watson Ltée — creators of SecurePi (sovereign OS) and HopChat (sovereign encrypted messaging)

HopChat | MessageSecure Comparison
HopChat Sovereign Architecture
HopChat Sovereign Architecture

The only messaging platform built with NIST-approved Post-Quantum Cryptography. No phone numbers. No cloud. No compromise.

Level 5
NIST PQC
GOLD
17
Apps Compared
70+
Security Criteria
100%
Sovereign
PQC vs Legacy

HopChat vs PGP / GPG

PGP (Pretty Good Privacy) and its open-source implementation GPG have been the gold standard for encrypted communications since 1991. But the cryptographic landscape has fundamentally changed. Here's why HopChat / MessageSecure represents the next generation.

⚠️ PGP / GPG
RSA / ECC encryption — vulnerable to quantum attack. IETF post-quantum OpenPGP draft (ML-KEM + ML-DSA) still in working draft stage, not deployed anywhere in production.
✅ HopChat / MessageSecure
ML-KEM-1024 live in production — NIST-standardized post-quantum key encapsulation with per-session ephemeral keys and forward secrecy. Quantum-safe today, not someday.
⚠️ PGP Key Management
Manual key exchange, web of trust, key servers, revocation certificates. Steep learning curve unsuitable for non-technical operators, journalists, or field teams.
✅ HopChat Key Management
Automatic, operator-controlled — sovereign key lifecycle with zero user friction. Consumer-grade UX with military-grade cryptography. Deploy on a Raspberry Pi in minutes.
⚠️ PGP Forward Secrecy
None — same long-lived key pair used for years. If a private key is compromised, all past messages are exposed.
✅ HopChat Forward Secrecy
Per-session ephemeral keys — each conversation uses unique keys that are destroyed after use. Past messages remain secure even if a key is later compromised.

PGP remains a proven standard for classical threat models. HopChat / MessageSecure is its post-quantum successor — sovereign, automated, and ready for the quantum era. See the full comparison in the table below.

Sovereign‑Grade Comparison Matrix

HopChat | MessageSecure is not a cloud messenger. It is a sovereign, enclave‑based, post‑quantum communication system designed for operators, founders, and organizations requiring deterministic security and predictable latency. This matrix contrasts HopChat with major cloud‑dependent platforms.

Criterion HopChat | MessageSecure Signal WhatsApp Telegram iMessage PQ3
Infrastructure Sovereign appliance (SecurePi), LAN/WireGuard only, no cloud. Cloud servers, US‑based. Meta global cloud clusters. Hybrid cloud + proprietary MTProto. Apple iCloud‑anchored routing.
Cryptography ML‑KEM‑1024 PQC, AES‑256‑GCM, SHA‑3, ciphertext‑only storage. Pre‑quantum E2EE (X3DH + Double Ratchet). Signal‑derived E2EE. MTProto 2.0 (non‑PQC). PQ3 hybrid PQC (Apple proprietary).
Metadata Exposure No phone numbers, no analytics, no telemetry, no cloud logs. Phone number required. Phone number + Meta analytics. Phone number + cloud identifiers. Apple ID + device identifiers.
Identity Model Anonymous sovereign IDs, QR‑verified, no SIM dependency. Phone number identity. Phone number identity. Phone number identity. Apple ID identity.
Hosting Runs on your hardware, your LAN, your WireGuard enclave. Signal Foundation cloud. Meta cloud. Telegram cloud. Apple cloud.
Routing Path Direct: Hollywood → WireGuard → Pi → PostgreSQL. Global relay servers. Meta global routing. Telegram global routing. Apple push + iCloud routing.
Latency 5–10 ms LAN, 30–120 ms WireGuard LTE/5G. 300–800 ms typical. 300–800 ms typical. 300–800 ms typical. 200–600 ms typical.
Cloud Dependency None. Zero. Fully sovereign. Full cloud dependency. Full cloud dependency. Full cloud dependency. Full cloud dependency.
Storage Model Ciphertext‑only PostgreSQL on your Pi. Cloud‑assisted metadata. Cloud‑assisted metadata. Cloud storage for groups. iCloud‑anchored metadata.
Sovereign Compliance Meets sovereign appliance doctrine; no foreign routing. No sovereign mode. No sovereign mode. No sovereign mode. No sovereign mode.
Gov‑Capability Mode Operator‑grade, enclave‑only, PQC‑ready. Not available. Not available. Not available. Not available.

HopChat | MessageSecure is not a competitor to cloud messengers. It is a sovereign communication platform engineered for environments where cloud routing, metadata exposure, and foreign infrastructure are unacceptable. It is a different species, not a “David” fighting a “Goliath.”

The Core Insight: Sovereign Enclave with Frictionless Public Ingress

HopChat | MessageSecure achieves something that most sovereign‑tech architects only discover after years of field experience: a sovereign enclave can remain fully dark while still offering a frictionless, public‑facing API — but only when ingress is controlled through a dual‑firewall cascade. This is the same hardened pattern used in NATO tactical enclaves, government‑grade SCIF networks, zero‑trust DMZ architectures, and high‑assurance sovereign clouds.

Security Principle HopChat | MessageSecure Implementation
Dual‑Firewall Cascade Helix Fi (outer gate) and Flint 3 (inner gate) form a chained ingress corridor. Only traffic explicitly destined for HTTPS 5001/TCP is permitted to traverse both layers.
Dark‑Core Architecture The SecurePi remains completely non‑enumerable: no SSH, no PostgreSQL, no admin ports, no WireGuard leakage, and no LAN discovery surface. Only the sovereign API endpoint is exposed.
Minimal Attack Surface A single hardened port — 5001/TCP — is the only externally reachable interface. All other ports are silently dropped at the hardware boundary.
Zero‑Trust Routing Public browsers reach the API through a controlled ingress corridor, while the internal enclave remains sealed. No lateral movement is possible, and no internal topology is revealed.
Sovereign‑Cloud Parity Mirrors high‑assurance sovereign cloud patterns: bright edge, dark core, strict ingress, and deterministic packet paths enforced at the hardware level.

This architecture allows HopChat to offer a public, zero‑friction onboarding experience while maintaining a sovereign, non‑enumerable, post‑quantum enclave behind the scenes. It is the foundation of HopChat’s Phase‑10 security posture and a defining advantage over cloud‑dependent messengers.

Public‑Safe Disclosure Policy

HopChat | MessageSecure follows a strict public‑safe disclosure model that balances transparency with sovereign‑grade operational security. The system reveals principles, not configurations, ensuring public trust without enabling reconnaissance.

Disclosure Category Public‑Safe Summary
High‑Level Architecture Publicly describes sovereign enclave principles, PQC usage, and metadata‑minimization doctrine without revealing internal topology.
Attack Surface Only one hardened ingress port is disclosed. No internal ports, services, or admin interfaces are ever revealed.
Threat Model Transparency Publicly outlines the classes of threats HopChat is designed to resist (MITM, metadata harvesting, cloud compromise) without exposing internal mitigations.
Non‑Disclosure Boundaries Internal IPs, WireGuard keys, OS versions, database schemas, and systemd service names are never disclosed publicly.

What HopChat Never Reveals

HopChat | MessageSecure follows a strict sovereign‑grade non‑disclosure doctrine. The system is transparent about principles but never exposes operational details that could enable reconnaissance or lateral movement. These boundaries are absolute.

Category Non‑Disclosed Elements
Internal Network Topology No LAN IPs, no WireGuard subnets, no routing tables, no enclave coordinates, no device fingerprints.
Cryptographic Secrets No TLS private keys, no PQC key material, no WireGuard keys, no signing keys, no certificate paths.
System Internals No OS versions, no kernel versions, no systemd service names, no directory structures, no package lists.
Database & Storage No PostgreSQL schemas, no table names, no query structures, no storage paths, no logs containing internal details.
Administrative Interfaces No admin URLs, no ports, no dashboards, no management endpoints, no health endpoints outside the enclave.

These boundaries ensure HopChat remains non‑enumerable, dark‑core sealed, and sovereign‑safe even under active probing or adversarial scanning.

Security FAQ — Public‑Safe Summary

This FAQ provides a high‑level, public‑safe overview of HopChat’s security posture. It answers common questions without revealing internal details or operational configurations.

Question Answer
Does HopChat use post‑quantum cryptography? Yes. HopChat uses ML‑KEM‑1024, AES‑256‑GCM, and SHA‑3 to secure all message envelopes against classical and quantum adversaries.
Does HopChat store any metadata? No. HopChat stores only ciphertext. No phone numbers, no analytics, no telemetry, and no cloud logs.
Is HopChat dependent on cloud infrastructure? No. HopChat runs on user‑owned hardware inside a sovereign enclave. Cloud infrastructure is never required for message delivery.
How is the system protected from external attacks? A dual‑firewall cascade exposes only a single hardened HTTPS port. All other services remain sealed and non‑enumerable.
Can attackers scan or enumerate the enclave? No. The enclave reveals no banners, no version strings, no admin ports, and no internal topology. All probes are silently dropped.

This FAQ provides clarity for users while maintaining the strict non‑disclosure boundaries required for sovereign‑grade security.

Legal & Compliance — CANSEC‑Grade Footer

HopChat | MessageSecure is developed by IA Watson Ltée and adheres to sovereign‑grade security, privacy, and compliance principles. The following statements define the legal boundaries and operational guarantees of the platform.

Clause Statement
Sovereign Hosting All data remains on user‑owned hardware. No foreign routing, no cloud storage, and no third‑party access.
Data Ownership Users retain full ownership of all encrypted content. IA Watson Ltée has no access to plaintext or metadata.
Operational Transparency Public documentation describes principles only. Internal configurations, keys, and system details remain confidential.
Responsible Disclosure IA Watson Ltée supports good‑faith security research and provides safe‑harbor protections for researchers acting within policy.
Non‑Enumerability Guarantee The enclave exposes no internal services, ports, or version information. All unauthorized probes are silently dropped.

These legal and operational guarantees ensure HopChat meets the expectations of defense, enterprise, and sovereign‑tech evaluators at CANSEC and beyond.

Dual‑Firewall Cascade — Sovereign Ingress Diagram

HopChat | MessageSecure uses a dual‑firewall cascade to maintain a dark‑core enclave while still allowing frictionless public access to the sovereign API. This diagram illustrates the controlled ingress corridor that protects the SecurePi from enumeration, probing, and lateral movement. 

┌──────────────────────────────────────────────────────────────────────────────┐
│                           PUBLIC INTERNET (HTTPS)                            │
└──────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                         OUTER GATE — BELL FIBE / HELIX FI FIREWALL           │
│  • Drops all unsolicited traffic                                             │
│  • Allows only TCP 5001 → Flint 3 WAN                                        │
│  • No SSH, no admin ports, no scanning surface                               │
└──────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                         INNER GATE — FLINT 3 FIREWALL                        │
│  • Second validation layer                                                   │
│  • Forwards only TCP 5001 → SecurePi                                         │
│  • Silently drops all other packets                                          │
└──────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                         SOVEREIGN ENCLAVE — SECUREPI                         │
│  • Kestrel bound to HTTPS 5001 only                                          │
│  • No LAN enumeration, no admin ports, no SSH exposure                       │
│  • PQC envelope processing, ciphertext‑only storage                          │
└──────────────────────────────────────────────────────────────────────────────┘

This ingress corridor ensures that HopChat remains publicly accessible while the internal enclave stays sealed, non‑enumerable, and sovereign‑safe.

HopChat | MessageSecure — Sovereign Architecture

HopChat is not a cloud messenger. It is a sovereign, post‑quantum communication platform built on a sealed enclave, hardware‑anchored routing, and a dual‑firewall ingress corridor. The architecture is engineered for operators, founders, and organizations who require deterministic security, predictable latency, and complete control over their data.

Sovereign Hardware

Runs on user‑owned SecurePi hardware inside a private enclave. No cloud compute, no foreign routing, no third‑party access.

Post‑Quantum Encryption

ML‑KEM‑1024, AES‑256‑GCM, and SHA‑3 secure every message envelope against classical and quantum adversaries.

Zero‑Trust Ingress

A dual‑firewall cascade exposes only a single hardened HTTPS port. All other services remain sealed and non‑enumerable.

HopChat delivers sovereign‑cloud parity with a dark‑core architecture, ensuring that users gain the benefits of modern messaging without surrendering control to external infrastructure.

Sovereign Threat Model

HopChat | MessageSecure is engineered to withstand modern adversaries across multiple threat classes. This sovereign‑grade threat model outlines the categories of attacks the system is designed to resist without revealing internal configurations or operational details.

Threat Class Mitigation Strategy
Network‑Level MITM PQC‑sealed envelopes, TLS 5001 ingress, and non‑enumerable endpoints prevent interception, replay, or downgrade attacks.
Cloud Compromise No cloud dependency. All message processing occurs inside a sealed, user‑owned enclave with ciphertext‑only storage.
Metadata Harvesting No phone numbers, no analytics, no telemetry, no logs. HopChat reveals no sender, recipient, or timing metadata.
Port Scanning & Enumeration Dual‑firewall cascade exposes only a single hardened HTTPS port. All other packets are silently dropped at the hardware boundary.
Supply‑Chain Attacks Local hardware, local routing, and no third‑party compute eliminate cloud‑based supply‑chain vectors.

This threat model ensures HopChat remains resilient against modern adversaries while preserving the sovereign, dark‑core architecture that defines Phase‑10.

PQC Envelope Flow — Phase‑10 Message Pipeline

Every HopChat message is wrapped in a post‑quantum cryptographic envelope before leaving the device. This diagram illustrates the high‑level flow without revealing internal keys or implementation details. 

┌──────────────────────────────────────────────────────────────────────────────┐
│                         1. USER INPUT (Hollywood UI)                         │
│  • Plaintext typed locally                                                   │
│  • Never transmitted unencrypted                                             │
└──────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                     2. PQC ENVELOPE BUILDER (Client‑Side)                    │
│  • ML‑KEM‑1024 key encapsulation                                             │
│  • AES‑256‑GCM symmetric sealing                                             │
│  • SHA‑3 hashing                                                             │
│  • Output: ciphertext‑only envelope                                          │
└──────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                     3. SOVEREIGN API (HTTPS 5001 Ingress)                    │
│  • Dual‑firewall cascade                                                     │
│  • TLS‑wrapped transport                                                     │
│  • No metadata leakage                                                       │
└──────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                     4. SECUREPI (Dark‑Core Enclave)                          │
│  • Ciphertext‑only storage                                                   │
│  • No plaintext ever written to disk                                         │
│  • PQC decryption occurs only at recipient side                              │
└──────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                     5. RECIPIENT DEVICE (Hollywood UI)                       │
│  • PQC envelope opened locally                                               │
│  • Plaintext reconstructed only on device                                    │
│  • Never exposed to servers or cloud                                         │
└──────────────────────────────────────────────────────────────────────────────┘

This pipeline ensures plaintext exists only on user devices, never on servers, never in transit, and never in the cloud.

HopChat vs Pegasus‑Class Threats

Pegasus‑class spyware targets devices, not servers. HopChat’s sovereign architecture minimizes the impact of such threats by eliminating cloud dependency, metadata exposure, and server‑side plaintext. This matrix outlines the defensive posture without revealing internal mechanisms.

Threat Vector HopChat Defense Posture
Device Compromise (Pegasus‑Class) Plaintext exists only on devices. No server‑side plaintext means compromise does not expose historical messages or metadata.
MITM Interception PQC‑sealed envelopes and TLS ingress prevent interception, replay, or manipulation of messages in transit.
Cloud Exploitation No cloud compute, no cloud storage, and no cloud metadata eliminate the primary attack surface exploited by Pegasus‑class actors.
Server Enumeration Single‑port ingress, dual‑firewall cascade, and non‑enumerable endpoints prevent attackers from discovering internal services.
Metadata Harvesting No phone numbers, no analytics, no telemetry, and no logs ensure Pegasus‑class actors cannot reconstruct communication patterns.

HopChat’s sovereign architecture ensures that even advanced spyware cannot access server‑side plaintext, metadata, or routing information — preserving long‑term confidentiality.

This policy ensures HopChat remains transparent to users while remaining non‑enumerable to attackers, preserving the integrity of the sovereign enclave.

Security Overview — Public‑Facing Summary

HopChat | MessageSecure provides a sovereign, post‑quantum secure messaging environment engineered for operators, founders, and organizations requiring deterministic security. This overview summarizes the system’s public‑safe security posture.

Security Domain Overview
Post‑Quantum Cryptography Uses ML‑KEM‑1024, AES‑256‑GCM, and SHA‑3 to secure all message envelopes against classical and quantum adversaries.
Metadata Minimization No phone numbers, no analytics, no telemetry, and no cloud logs. Only ciphertext is stored.
Sovereign Hosting Runs on user‑owned hardware inside a private enclave. No foreign routing, no cloud dependency.
Zero‑Trust Ingress Only a single hardened HTTPS port is exposed. All other services remain sealed behind a dual‑firewall cascade.

This overview provides a public‑safe snapshot of HopChat’s security posture without revealing internal configurations or operational details.

CANSEC‑Grade Disclosure Matrix

This matrix outlines what HopChat | MessageSecure discloses to public users, evaluators, and sovereign‑grade procurement teams. It is designed for high‑assurance environments where clarity and boundaries are essential.

Audience Disclosure Level
Public Users High‑level architecture, PQC usage, metadata policy, and sovereign principles. No internal details or operational data.
Evaluators / Analysts Threat model summaries, envelope design principles, and enclave behavior. No keys, configs, or internal topology.
Procurement Teams NDA‑protected documentation including audit summaries, PQC envelope specifications, and sovereign compliance attestations.
Appliance Owners Full local transparency: logs, metrics, health endpoints, and enclave‑internal diagnostics — never exposed publicly.

This matrix ensures HopChat remains transparent where appropriate and sovereign where required, meeting CANSEC‑grade expectations.

Responsible Disclosure Policy

HopChat | MessageSecure welcomes good‑faith security research and follows a responsible disclosure model aligned with sovereign‑tech best practices. This policy outlines expectations for researchers and the commitments made by IA Watson Ltée.

Policy Element Description
Good‑Faith Research Researchers may test publicly exposed components without attempting to access private systems, internal networks, or non‑public data.
Reporting Process Vulnerabilities should be reported privately to IA Watson Ltée with sufficient detail to reproduce the issue.
Non‑Disclosure Window Researchers agree not to publicly disclose vulnerabilities until a fix has been developed and deployed.
Legal Safe Harbor IA Watson Ltée will not pursue legal action against researchers who follow this policy and act in good faith.

This policy ensures that security research strengthens HopChat without compromising the integrity of the sovereign enclave.

Why HopChat Exists

The Sovereign Edge: The Post-Quantum E2EE Breakthrough

While industry giants like Apple and the GSMA are beginning to integrate end-to-end encryption (E2EE) into mainstream standards like RCS, these implementations remain tethered to centralized corporate silos that manage your identity, route your metadata, and rely on legacy classical cryptography. This creates a dangerous "trust gap" where privacy is merely leased from a provider rather than owned by the user. Even as platforms like Signal lead the commercial space with hybrid post-quantum experiments, the fundamental flaw remains a centralized corporate infrastructure that forms massive honey-pots for surveillance and cyberattacks.

HopChat | MessageSecure represents a paradigm-shifting breakthrough by completely replacing corporate-managed keys with absolute digital sovereignty. By shifting the entire cryptographic brain to the SecurePi—a decentralized, owner-controlled hardware node—we physically decouple your privacy from the cloud.

Operating under advanced Phase 10 protocols, our architecture utilizes a hybrid ML-KEM (Kyber-1024) mechanism for key exchange and ML-DSA (Dilithium-65) for identity anchoring, building an impenetrable, "Shor-resistant" shield against future quantum decryption. Unlike mainstream solutions that route cross-platform traffic through vulnerable corporate corridors, every identity here is anchored in local hardware, and every packet is encapsulated in post-quantum armor.

By ensuring absolute long-term confidentiality and radical metadata minimization, HopChat delivers a sovereign private infrastructure truly resilient against both current surveillance and future quantum threats. This is not just a software update—it is a physical move to a world where you, and you alone, hold the absolute keys to the kingdom.

The right to private communication is fundamental — and it is under siege. Classical encryption schemes that protect the world's digital conversations today will be broken by sufficiently powerful quantum computers within this decade. Most messaging platforms know this. None have acted.

HopChat was founded on a single conviction: that every person, organization, and government deserves messaging infrastructure that is mathematically secure against both present-day adversaries and the quantum computers of tomorrow — without sacrificing usability, without surrendering data to third-party servers, and without a phone number, an email address, or any personally identifying information required to get started.

Sovereign Cryptography & Infrastructure Glossary

GSMA Global System for Mobile Communications Association
The Corporate Standard vs. HopChat Isolation

A massive corporate telecom consortium representing over 750 global network operators. The GSMA dictates the profile standards for consumer cellular infrastructure. Because its cryptographic standards rely on absolute bureaucratic consensus among corporate and state monopolies, its protocols run on legacy corridors. HopChat intentionally drops beneath this layer, routing your communications completely outside of GSMA-managed carrier infrastructure by running directly through your private, owner-controlled SecurePi mesh.

RCS Rich Communication Services
The Big Tech Legacy Corridor vs. SecurePi Node Routing

The modern text messaging protocol pushed by Google and Apple to achieve cross-platform multimedia interoperability. While commercial apps overlay basic encryption onto RCS, it structurally forces your traffic through cellular operator servers and corporate cloud hubs, leaving your system metadata completely exposed. HopChat | MessageSecure shatters this reliance by establishing direct, hardware-to-hardware data handling on the SecurePi, ensuring your routing logs and conversational identity remain entirely private and completely isolated from Big Tech's databases.

E2EE End-to-End Encryption
The Centralized Trust Gap vs. Absolute HopChat Sovereignty

A standard paradigm where payloads are encrypted on the device and only decrypted by the receiver. However, standard apps like WhatsApp or iMessage maintain a deep trust gap: the companies own the centralized registry servers that hand out the public keys, allowing them the theoretical power to perform key-substitution operations. HopChat brings a historic breakthrough to E2EE by completely removing corporate-managed directories; your SecurePi serves as your independent identity anchor, giving you absolute ownership of the keys.

ML-KEM (Kyber-1024) Module-Lattice-Based Key Encapsulation Mechanism
Mainstream PQC Experiments vs. HopChat Max-Grade Armor

The pinnacle NIST-standardized public-key encapsulation protocol (FIPS 203) designed to withstand quantum computer cryptanalysis using multidimensional lattice math. While competitors like Signal utilize lower security variants (Kyber-768) wrapped over traditional systems in hybrid configurations, HopChat enforces full ML-KEM-1024 parameters. This brings Level 5 cryptographic security—equivalent to or exceeding AES-256 brute-force hardness—directly to your SecurePi, ensuring communications cannot be targeted by "Harvest Now, Decrypt Later" quantum collection strategies.

ML-DSA (Dilithium-65) Module-Lattice-Based Digital Signature Algorithm
Classical Spoofing Vulnerabilities vs. The SecurePi Sentinel Gate

A highly advanced post-quantum digital signature algorithm (FIPS 204) built on the mathematical complexity of module lattice vector configurations. While commercial networks still verify signatures using legacy classical cryptography (vulnerable to upcoming quantum extraction), HopChat locks its entire infrastructure behind an ML-DSA-65 verification loop. Operating on the SecurePi as a dedicated Sentinel Gate, this logic strictly audits every single incoming packet, instantly dropping untrusted, altered, or forged code vectors before they can interact with the system.

Shor-Resistant Resilient Against Shor’s Quantum Algorithm Execution
Legacy Internet Obsolescence vs. The HopChat Immutable Vault

An engineering standard confirming that a system's core mathematical math is entirely immune to execution under Shor’s Algorithm. Traditional public-key schemes (RSA, ECC, Diffie-Hellman) rely on integer factorization that quantum platforms can shatter instantly. By moving away from legacy integer structures and deploying geometric module lattices, the HopChat | MessageSecure paradigm remains entirely Shor-resistant, ensuring that transactions handled by your decentralized SecurePi are mathematically secure across the horizon of quantum expansion.

Toolbar Button Reference

// Composition Controls
✦

New

Opens a blank message composer and launches the recipient selection screen. Use this to initiate a fresh one-to-one or group conversation with any HopChat contact or ID. A new Double Ratchet handshake is performed automatically when the first message is sent.

⬡ Keyboard shortcut: Ctrl + N on desktop
▶

Send

Encrypts the current message composition (text + any attachments) with the recipient's ML-KEM-1024 public key, advances the Double Ratchet session state, and transmits the resulting ciphertext through the zero-knowledge relay. The button is active only when both a recipient and message content are present.

⬡ Messages are encrypted locally before leaving your device
// Contacts & Recipients
👤

Contacts

Opens your HopChat address book — a local, encrypted list of contacts you have verified and saved. Each contact entry stores the person's HopChat ID and their verified public key fingerprint. Your contacts list is stored exclusively on your device and is never synced to HopChat servers.

⬡ Import contacts via QR code scan or manual HopChat ID entry
✔

Choose Recipients

Opens the recipient picker for the current message. Search by HopChat display name or ID, or select from your Contacts. For group messages, add multiple recipients sequentially. Each recipient's public key is fetched and verified before encryption — you will be warned if a key has changed since your last conversation.

⬡ Key-change warnings require your manual re-verification before sending
// Media & Attachments
📎

Attach

Opens your device's file browser to select any document, PDF, spreadsheet, archive, or other file for attachment. Selected files are chunked and encrypted client-side before upload. The server receives only encrypted binary chunks and has no visibility into file type, name, or content.

⬡ Max attachment size: 2 GB per file
📷

Camera

Opens your device camera to capture a new photo directly within HopChat. The captured image is encrypted immediately in memory before being written to any temporary storage — it is never saved to your device's camera roll unless you explicitly save it. Tap to shoot; confirm to attach to the message.

⬡ Images are stripped of EXIF metadata before encryption
🎬

Video

Opens your device camera in video recording mode. Record a clip and confirm to attach it encrypted to your outgoing message. As with photos, video files are encrypted in memory and stripped of metadata before transmission. Long recordings are streamed in encrypted chunks rather than buffered entirely.

⬡ Video clips are encrypted frame-by-frame before upload
🎙

Voice

Records a voice note using your device microphone. Tap once to begin recording (you will see a waveform and timer), tap again to stop. The audio is immediately encrypted and attached to the current message. Voice notes appear as playable waveforms in the recipient's conversation thread.

⬡ Max voice note duration: 10 minutes
// Screen Sharing
🖥

Share My Screen

Initiates a live screen share of your device display to the current call participant. Screen share data is transmitted over the same post-quantum encrypted WebRTC channel as the voice/video call. The remote party can see your screen in real time. Tap again to stop sharing at any moment.

⬡ Available during active voice or video calls only
↙

Ask to Share Screen

Sends the other call participant a request to share their screen with you. They will receive a prompt that they must explicitly accept before their screen becomes visible to you. This button does not force or enable screen sharing on the remote device — consent is always required from the other party.

⬡ Request can be declined at any time by the remote party
// Security Controls
⚠

Kill Switch

CRITICAL — IRREVERSIBLE. Activating the Kill Switch immediately and permanently destroys all HopChat data on the device: message history, encryption keys, contact list, session state, and application configuration. There is no recovery, no backup, and no undo. This feature is intended for use in high-risk situations where device seizure or compromise is imminent.

⚠   You will be prompted with a confirmation dialog before the Kill Switch executes. In your Settings, you may configure the Kill Switch to trigger automatically after a specified number of failed authentication attempts. Once activated, your HopChat account and all data are gone — you would need to create a new account and re-verify contacts from scratch.
🔑

Generate Private / Public Key Pair

Generates a new hybrid post-quantum cryptographic keypair on your device: an ML-KEM-1024 (CRYSTALS-Kyber) key for encryption/key-encapsulation and an ML-DSA (CRYSTALS-Dilithium) key for digital signatures. Key generation happens entirely on-device using a cryptographically secure random number generator. Your private key is never transmitted, stored in the cloud, or accessible to HopChat. Use this button to initialize a new account or to rotate your keys if you suspect a compromise.

⬡ Key generation takes approximately 1–2 seconds on modern hardware
⬡   After generating a new keypair, share your new public key fingerprint with your contacts so they can re-verify your identity. Previous conversations encrypted to your old key cannot be decrypted with a new keypair.

Data sourced from securemessagingapps.com analysis, enriched with sovereign architecture specifications.

⬡   Help ⬡   Full Comparison ⬡   About ⬡   FAQ ⬡   Summary