A modern, cross-platform email encryption tool that bridges Nostr and email protocols. Discover contacts through the decentralized social key registry and send encrypted emails with a single click.
Everything you need to take control of your email communications, with the power of Nostr's decentralized key infrastructure.
Emails are encrypted using NIP-44 (or NIP-04) with secp256k1 key pairs. Only the sender and recipient can read the content -- not even your email server.
Built with Tauri for native performance on Windows, macOS, Linux, and Android. One codebase, every platform.
Discover contacts through Nostr's decentralized social key registry. No manual key exchange -- just follow someone and start sending encrypted mail.
Send and receive encrypted direct messages through the Nostr relay network, alongside your email -- all from one interface.
Sign outgoing emails with Schnorr signatures so recipients can verify authenticity and detect tampering.
Hybrid encryption for file attachments: AES-256 encrypts the payload, and NIP-44 protects the symmetric key.
A modern, clean interface with dark and light themes. Responsive design looks great on desktops and mobile devices alike.
SQLite local storage caches contacts, profiles, and messages so you can work offline and sync when you reconnect.
Works alongside existing Nostr clients like Amethyst, Damus, and others. Your keys, your network, your choice of tools.
Bridging the gap between Nostr's key infrastructure and email's ubiquity.
Use your existing Nostr keypair (nsec) or generate a new one. Your private key never leaves your device.
Your Nostr follow list is loaded automatically. Each contact's public key is fetched from relays -- no manual key exchange needed.
Write your email as usual. nostr-mail derives a shared secret from your private key and the recipient's public key, then encrypts the message.
The encrypted payload is delivered through your configured SMTP server. Optionally, the subject is also sent as a Nostr direct message to notify the recipient.
The recipient's nostr-mail client fetches the email via IMAP, derives the same shared secret from their private key and the sender's public key, and decrypts the message.
Nostr and email each solve problems the other can't. nostr-mail combines the best of both.
| Feature | Nostr | nostr-mail | |
|---|---|---|---|
| Social Key Registry | |||
| PGP Encryption | |||
| Long Form Content | |||
| Archival Storage | |||
| Ubiquitous |
Several projects share the name “Nostr mail” but not the architecture. Nmail is relay-native: it replaces SMTP with Nostr relays and bridges out to legacy email when it has to. Mailstr is a hosted gateway: it sells you an address, receives ordinary email on your behalf, encrypts it to your key, and stores it on relays. nostr-mail is neither — it is an encryption layer over the email you already have, so the ciphertext is produced on your device and travels over standard SMTP. All three are valid designs; they just put the trust boundary in different places.
| Aspect | nostr-mail | Nmail (nostrmail.org) | Mailstr (mailstr.app) |
|---|---|---|---|
| What it is | Native client (Tauri) you run yourself | Protocol + reference client and SDKs | Hosted service with a web inbox |
| Where encryption happens | On your device, before the message ever reaches SMTP | On your device, before the event reaches a relay | On their bridge, after it receives your mail in plaintext |
| Trust in an operator | None — there is no operator in the path | Relays store gift-wrapped events; bridges see plaintext when used | The bridge is a trusted party at ingest — it performs the encryption |
| End-to-end scope | True E2E between two nostr-mail users, across arbitrary providers (Gmail ↔ Outlook ↔ Proton) | E2E within the Nostr network; messages leaving via an SMTP bridge are plaintext after the bridge | Bridge→you leg only. They say so plainly: the sender→bridge leg is ordinary email |
| Transport & storage | Standard SMTP & IMAP; archived by your existing provider | Nostr relays (custom event kinds, e.g. 1301); retention depends on relays | Inbound SMTP, then stored on the Nostr relays you choose |
| Address & discovery | Your existing addresses, published via your Nostr profile (kind 0) | Nostr identity / NIP-05 | you@mailstr.app, which doubles as your NIP-05 handle |
| Counterparty adoption | Both sides need nostr-mail for E2E; without it you are sending ordinary email | Correspondent needs Nostr, or a bridge in between | None — anyone with a normal inbox can reach you today |
| Metadata hiding | Subject and body encrypted, then encoded as natural-looking text (Glossia) | Full envelope hidden via NIP-59 gift wrapping | Inbound envelope is visible to the bridge; ciphertext at rest on relays |
| Attachments | AES-256 with NIP-44 key wrapping, embedded directly in MIME | Out-of-band storage (Blossom servers) with hybrid referencing | Not advertised |
| Size ceiling | Your provider’s message limit (commonly ~25 MB), against a mailbox quota measured in gigabytes | Relay event limits, sidestepped by pushing blobs to Blossom and referencing them | Whatever the relays accept — no blob offload published |
| Cost | Free, MIT licensed | Free, MIT licensed | One-time Lightning payment to claim the name |
| Platforms | macOS, Windows, Linux, Android (zapstore) | Web, Linux, Android (zapstore) | Web |
The difference that matters most is who holds the plaintext. Mailstr is unusually honest about this — they state up front that the sender-to-bridge leg is ordinary email and not end-to-end encrypted, which most providers never mention. But the consequence runs deeper than the caveat suggests: because their bridge is what performs the encryption, it necessarily sees every inbound message in the clear. It is a trusted party, not a passive relay. nostr-mail has no such party in the path — ciphertext is produced on your machine and no one but the recipient can open it. The same limitation applies to any Nmail message that arrives through an SMTP bridge.
Relays were built to broadcast, not to archive. Every relay advertises a max_message_length (NIP-11), and the values in the wild vary by more than an order of magnitude — so anything stored as a relay event inherits whatever ceiling the strictest relay in your set applies, and a large attachment simply will not fit. Nmail confronts this directly by pushing blobs to Blossom servers and referencing them from the event. Mailstr has not published how it handles large attachments. IMAP needed no such workaround: it was designed for storage from the start, with multi-megabyte MIME messages, folders, server-side search, and retention your provider already operates — which is what nostr-mail encrypts into rather than replacing.
Mailstr is closer to complementary than competitive. Its real advantage is that it requires zero adoption from the people writing to you, where our end-to-end encryption only engages when your correspondent also runs nostr-mail. A @mailstr.app address as a durable inbound identity, with nostr-mail handling E2E whenever the other side is on Nostr, would be a coherent pairing. The obstacle today is storage, not intent: Mailstr keeps your mail on Nostr relays rather than in an IMAP mailbox, and nostr-mail reads IMAP — so our client cannot open a Mailstr inbox. If they ever expose IMAP, this becomes a straightforward integration. Separately, we are exploring relay transport (NIP-59 gift wrapping) alongside SMTP/IMAP, giving users a spectrum between maximum reach and maximum metadata privacy.
No framework bloat. Built on a lean, auditable stack you can trust.
Get started with nostr-mail today. Open source, free forever, and built for people who care about owning their communications.
