Here's a little passion project I've been working on!
- Concept and Onboarding
SimplePGP is more than just a messaging platform; it is infrastructure for private, end-to-end communication that does not require trusting a platform with your message contents. It is based on OpenPGP encryption so only the people in a conversation can read what is sent. Users create an account by generating a PGP keypair directly on their mobile device. The public key becomes their identity, so anyone can verify it's them and no one can impersonate them without the key. Identity is tied to cryptography rather than a company's user database.
2. How it works
Messages are encrypted on the client (Android or web) before they leave the device, sealed to the recipient's public key and wrapped again in TLS for transit. They are then relayed through a server that routes armored ciphertext during delivery. The server never has access to plaintext and never holds a private key. Direct messages, group chats, and public "nodes" (IRC-style channels) all share the same encrypted messaging model, alongside peer-to-peer voice and video calls where the server handles signaling only and the media flows directly between devices.
Unlocking the private key takes more than a password. At signup, the password and a biometric-gated secret are each stretched through salted PBKDF2-SHA256 (200,000 iterations) and XOR-combined into a single 256-bit shard that protects the key. Meaning, neither factor alone gets an attacker anywhere.
Optional browser access is linked from the phone via QR login: the phone and browser perform an ECDH handshake, and the phone hands over the key vault AES-GCM-wrapped and bound to that specific browser tab, so the web session can use the same keys without pasting secrets into a form. In the browser, keys live in memory only and vanish when the session ends.
Alongside messaging, SimplePGP includes a lightweight economy layer: SPGP balance, inventory, and a trade desk with real cryptocurrency deposit invoices. Bitcoin is already implemented end to end (one-time deposit addresses with on-chain payment verification), with USDT, ETH, XMR, and other cryptocurrencies in active development. This lets users exchange value and items with people they already talk to, still under their own account control.
3. Problems it solves
Most messengers force a tradeoff: convenience versus privacy. Centralized apps can read, scan, or hand over message content; "encrypted" products often still bind you to a closed ecosystem and a company-owned identity. SimplePGP is built for the people who can't afford that tradeoff: whistleblowers, journalists, activists, and military personnel alike. It does this by making encryption the default path, keeping key material on the user's device, and exposing an auditable, self-hostable relay. Because routing follows public keys and the relay only ever sees ciphertext, there is no server-side inbox worth breaching and no operator who can be compelled to produce plaintext. It also reduces coordination friction for small communities (secure DMs, groups, and open nodes in one place) without requiring users to understand the full PGP toolchain up front.
- Client-side cryptography: Encryption and decryption happen on the device; the relay routes sealed payloads and is never the authority over message meaning.
- Hardware-bound keys: The private key is wrapped by the device's secure element and released only after a biometric scan, and even then it still requires the password. Two factors, enforced by hardware rather than app logic.
- Cross-Platform access: Native Android for daily use; a browser client for when you need a larger screen, linked securely from the phone with no key material typed or pasted.
- Human-scale coordination: Contacts, groups, and IRC-style nodes for real conversations, not algorithmic feeds.
- Optional value exchange: Trade and balance features sit beside chat so mutual aid and barter do not require a separate, less private app.
4. Project status
SimplePGP is in active development and nearing closed beta. The full feature set already runs end to end: encrypted direct messaging with decrypted previews on mobile, group creation and chat UI, nodes, WebRTC voice/video calls with screenshare, profile and inventory, an exchange/trade desk with live Bitcoin invoicing (more chains in development), and QR-linked web sessions against a Node/Express relay. It is not yet publicly hosted; test sessions currently run over an ngrok tunnel during development, with dedicated hosting planned for the beta. The stack: a vanilla JavaScript web client, an Express API with a WebSocket relay for message routing and call signaling, and a native Kotlin/Compose Android app with BouncyCastle key generation and hardware KeyStore protection. Every layer is ordinary, inspectable code with no proprietary black boxes in the message path, so contributors and judges can follow a message through the whole system and verify that the server only ever touches ciphertext.
What's next!
A few things are actively on the workbench. First, webhook support is being built into the node segment: self-hosted nodes will be able to trigger automations and power custom bots (moderation, scheduled announcements, community tooling), all running on the operator's own VPS, next to data they control. Under this design, every node gets its own PGP keypair: members encrypt messages to the node's public key, the VPS decrypts them with the node's private key, which is held only on that VPS, and immediately re-encrypts each message to every member's individual public key for delivery. Plaintext never crosses the wire and never touches the central relay; it exists only for a moment, in memory, on the machine the community itself runs. The trust boundary moves away from the platform to your own. Second, I'm looking into bringing SimplePGP to the Nimiq ecosystem as a mini-app, and I'd genuinely welcome advice on the project itself, and especially on the right way to get started with mini-app development. Third, work is underway to open-source parts of the stack, beginning with the local clients (Android and web): the code that actually handles key material should be the first thing anyone can independently audit. Lastly, I'm also looking for digital artists to create some icons for me! If any of this is interesting to you, feedback and pointers are very welcome.