Gm Dear Readers !
As I just promised here is the second part of the article, originally coming from dev.to.
Now fasten your belt and let's onwards we go with the description. In this I will describe alternative messengers that are looking promising, Let's go !
Sealed
What Sealed Actually Is (The Honest Technical Take) ?
Sealed is a blockchain-based, end-to-end encrypted messaging app built on a three-tier data architecture. Unlike most messengers that centralize everything on company servers, Sealed explicitly separates data into three distinct realms, each with different controllers. This is the critical design choice that sets it apart.
The app is currently live on iOS and Android, operating on Algorand. The foundational principle is brutal: no single party—not even Sealed's operators—has full control over all your data. That's architecturally honest in a way Signal and Telegram aren't.
The Three Data Realms: How the Architecture Actually Works
Realm A: Your Device (You Alone Control This)
Everything that matters cryptographically stays on your device. Your BIP39 seed phrase, your Ed25519 wallet signing key, your X25519 encryption keypair, and all decrypted message content lives exclusively in your device's secure enclave—iOS Keychain or Android Keystore. There is no recovery mechanism. If you lose your device without a seed phrase backup, your account is gone permanently. Sealed cannot recover it, nor can any authority compel them to.
Your contact list (wallet addresses plus usernames) also stays local. The implication here is clear: Sealed has zero visibility into your social graph. They can't tell who you're talking to, how often, or in what pattern.
Realm B: The Public Blockchain (No One Controls This)
Every message you send goes onto a public blockchain as an immutable transaction. This is where the privacy model gets interesting.
Messages are stored as AES-256-GCM encrypted ciphertext—unreadable without your private key. But the blockchain stores more than just content. Each message includes an ephemeral sender public key (a one-time X25519 key per message, not your permanent identity), a 32-byte HMAC recipient tag used for "stealth addressing," the block-level timestamp, and your sender wallet public key (your pseudonymous identity).
Here's the friction: if you register a human-readable username, that gets written to the blockchain permanently. This is where anonymity breaks if you're not careful. Register as "john_crypto_banker" and link your Twitter, and the pseudonymity collapses. But if you stay wallet-address-only, the blockchain sees only a pubkey, not a name.
The critical point: blockchain data is permanent and immutable. No deletion rights apply. You cannot request removal. An observer can see that a message was sent to a particular wallet address at a particular time, and if encrypted properly, they cannot read it. But the metadata—that a message exists, when it was sent, and who the recipient pseudonymous identity is—that's forever.
Realm C: The Indexer Server (Sealed Controls This, With Guardrails)
This is where Sealed takes a calculated privacy trade-off. To deliver push notifications and enable efficient message sync, they operate an indexer server that stores limited data:
- Your wallet public address (for identity and auth)
- Your X25519 view key (this is the big one—see below)
- SHA-256 hash of your view key
- Firebase Cloud Messaging token (for push delivery)
- Device platform identifier (iOS or Android)
- Optional username
- Message metadata pointers (blockchain transaction references for sync, not content)
- Last seen timestamp
- IP address (standard server logging)
The view key is the most significant privacy tradeoff and Sealed is honest about it. Your X25519 scan/view private key is shared with their indexer server. This allows the server to detect incoming messages addressed to you on-chain and trigger push notifications. The view key does not decrypt content—that's a separate key path. The view key only reveals that a message was sent to you, not what it says.
This is crucial: if Sealed's indexer is compromised, attackers learn who's messaging you. But they don't learn what was said. Content requires your full private key, which never leaves your device.
Retention is clear: indexer data expires after 90 days of inactivity. Message metadata expires after 30 days. IP logs rotate per standard practice (7–30 days). You can manually delete your account at any time with a signed deletion request, and they'll purge the view key and FCM token within 30 days.
Authentication: No Phone Number, No Email, No Password
Sealed uses pure wallet-based authentication. When you log in, your app signs a time-limited challenge string with your Ed25519 wallet private key. The signing key never leaves your device. This means there's no email-based password reset, no SIM-swap attack surface, no centralized identity store. You are your keys.
The tradeoff: if you lose both your device and your seed phrase, you're locked out forever. There's no "I forgot my password" recovery. This is hardcore, but it's the price of true key custody.
Encryption Details: Where Sealed Gets Technical
Message content uses AES-256-GCM with per-message ephemeral keys. The key derivation path is X25519 (ECDH) + HKDF, which is industry standard. Messages are padded to a uniform 1,024 bytes before encryption to prevent length-inference attacks—a sophisticated move that prevents attackers from guessing message type based on ciphertext size.
The ephemeral key per message is the Double Ratchet-adjacent concept: each message has a unique encryption key. This gives forward secrecy—if one key is compromised, only that one message is exposed, not past or future ones.
The roadmap includes ML-KEM-512 (Kyber-512) as a hybrid post-quantum layer on top of X25519. This is planned but not yet deployed. Currently Sealed is quantum-vulnerable, like all classical asymmetric crypto.
API communication to the indexer uses Ed25519 signature-based authentication with signed time-limited nonces, enforced over HTTPS/TLS. The server implements helmet security headers and rate limiting (100 requests/minute per IP).
What Sealed Does NOT Collect (The Important Negatives)
This is where Sealed differs sharply from WhatsApp, Telegram, and especially Messenger:
- No real name
- No email address
- No phone number
- No device contacts imported
- No location data
- No advertising identifiers (IDFA/GAID)
- No biometric data
- No analytics or behavioral tracking
- No crash reports or telemetry beyond server-side operational logs
This is a stark contrast to Signal, which collects your phone number and uses it as your identity. Sealed's wallet-first model means they have no way to know who you are unless you tell them.
Third-Party Dependencies: Where Trust Matters
Sealed uses only two external services:
Google Firebase Cloud Messaging (FCM): For push notifications. Sealed sends Firebase only your FCM device token and a notification payload containing the sender's wallet address and a message reference—not the message content. This means Google sees that you received a message from a particular wallet, but not what was said. Google's privacy policy applies to this data.
AlgoNode (Algorand RPC): A third-party public Algorand node. Transactions you broadcast are globally visible by nature. No personal identifying data beyond your wallet address and encrypted message ciphertext is transmitted.
Sealed explicitly does not use advertising networks, analytics platforms, or data brokers. This is a hard line.
The Privacy Model: Honest About Tradeoffs
Sealed is architected for a specific threat model: you want encryption that no single entity can break, pseudonymity rather than anonymity, and no central server controlling your social graph.
If your threat is a government subpoena, Sealed has a clean answer: indexer data expires, blockchain data is public, and Sealed cannot hand over decrypted messages because they don't have your private key. The police would need your device or seed phrase.
If your threat is Sealed itself, you get a partial win: Sealed cannot read your messages, but they can see who's messaging you (via the view key). If you're concerned about this, you should assume the view key is compromised.
If your threat is length-based message inference, Sealed padded messages to 1,024 bytes, so attackers can't guess what you're saying based on ciphertext size.
If your threat is quantum computers, you're vulnerable until they deploy Kyber-512.
The Uncomfortable Realities
Realm B is permanent: Anything you write to the blockchain stays forever. If you message someone's wallet address, that metadata (sender, recipient, timestamp, message reference) is immutable. In a world of blockchain analysis and wallet clustering, this is a permanent link. Sealed can't delete it, and neither can you.
The view key is a vulnerability: It's the single point where Sealed can learn your incoming message graph. If the indexer is breached, attackers get a list of everyone messaging you. Sealed is transparent about this, but it's still the biggest attack surface in the architecture.
Usernames break pseudonymity: If you register a human-readable name, it's on-chain forever. Anyone can link your wallet to your identity. Sealed can't prevent this; it's a user error problem.
Firebase adds a Google dependency: FCM tokens reveal to Google that you're using Sealed, and when you receive messages. Google's privacy standards are better than most, but it's still a third party with visibility.
No audit: The privacy policy doesn't mention any independent security audit. The encryption primitives (AES-256-GCM, X25519, HKDF) are solid, but there's no third-party verification that the implementation is correct.
How This Compares to the earlier mentioned ones ?
Sealed is architecturally more honest than Signal or SimpleX about what data they hold and why. Signal doesn't explain its data architecture; they just say "we don't store messages." Sealed breaks it down into three realms and explains the controller for each.
Sealed is less mature than Signal (which has been battle-tested for a decade) and less audited than SimpleX (which had Trail of Bits assessment).
Sealed is more decentralized than Telegram (which holds all data server-side) but less decentralized than Element (which is federated) or SimpleX (which has no central relays—queues are ephemeral).
Sealed is more private than WhatsApp or Messenger because it doesn't collect phone numbers, emails, or contact graphs.
NCrypt (Gen6 Dapp)
NCrypt is a decentralized messaging app built as part of the Gen6 ecosystem. It's E2EE messaging integrated with Gen6's decentralized identity system (Gen6.Me). Messages are encrypted, transmitted through Gen6 validator nodes, and stored on the Gen6 blockchain.
The Technical Stack:
Blockchain: Gen6's own chain (Enhanced Proof-of-Authority consensus)
Validator Network: 100+ distributed validators securing the chain
Identity Layer: Gen6.Me (verified, pseudonymous, or fully private)
Encryption: Not explicitly stated, but likely AES-256 or ChaCha20-Poly1305 (industry standard)
Storage: Encrypted messages on Gen6 blockchain
Roadmap: Q4 2026 includes post-quantum security upgrade
Integration with Gen6 Ecosystem:
NCrypt isn't standalone—it's one dApp in a larger system:
RealSeal: On-chain cryptographic signing and timestamping
Gen6.Me: Verifiable identity (proof-of-attendance, credentials)
FONO: Event verification and community management
GSX Token: Utility token for transaction fees and ecosystem incentives
The Reality Check:
NCrypt is more honest but less audited than it claims:
No independent security audit — Gen6 was founded by security experts (David Pethes, Sergey Gerodes) but that's not a substitute for third-party audit.
Validator-dependent privacy — Your messages go through Gen6 validators. If a validator node is compromised, they see metadata (though not content if encryption is solid)
Identity is optional but integrated — You can be pseudonymous, but the whole ecosystem incentivizes verified identity (which is good for trust, bad for pure privacy)
Post-quantum still in roadmap — They're targeting Q4 2026; currently quantum-vulnerable like most messengers.
Smaller community — ~30,000 users vs millions for Signal. Smaller attack surface, but also less battle-testing.
Summary
That was it for this part and see you in last part namely private mails, the most exciting one. Stay tuned !