economically impossible
Imagine email where every cold message must include a tiny “Satoshi Stamp”.
Not a “premium feature”. Not a subscription. Not ads.
Just pure physics: spam dies because it costs sats.
This is how you build the Gmail-killer: turn attention into a market and make inboxes default-private, default-owned, default-portable.
The 3 killer primitives
1) Satoshi Stamps (anti-spam by default)
- Unknown sender → must attach sats to reach you.
- You set your own “rate”:
- Friends: 0 sats
- Verified accounts: 0–10 sats
- Cold pitch: 250 sats
- “Don’t waste my time”: 5,000 sats
Result: Your inbox becomes a paywall against junk and a funnel for serious messages.
Optional twist: Refundable stamps via Lightning “hold invoices” (more below).
2) One identity that is both
email-ish
and
money-native
Use an email-like handle: name@domain.
- For payments, a Lightning Address is literally an internet identifier (“like an email address, but for Bitcoin”) and relies on LNURL-Pay.
- For messaging identity, Nostr’s NIP-05 maps that same email-like identifier to a public key + suggested relays.
So the same human-readable handle can resolve to:
- a Lightning payment endpoint (/.well-known/lnurlp/<name>),
- and a messaging public key + relay list (/.well-known/nostr.json?name=<name>).
3) Paid relays (you pay for storage/bandwidth, not surveillance)
Instead of Google scanning your life to sell ads, relays get paid in sats:
- pay-per-message
- pay-per-month mailbox
- pay-per-GB attachments
This makes the business model honest: the user (or sender) funds delivery.
One-minute user experience (the dopamine hit)
Cold email becomes:
- You type eric@kim.com
- SatMail instantly shows:
“Recipient requires 300 sats to accept cold mail.” - You attach 300 sats + hit send
- Message lands in Eric’s Paid Inbox (not spam)
- Eric taps:
- Accept → keeps sats
- Refund → sender gets sats back (if refundable stamp enabled)
- Block → sender can’t reach again without a huge bond
This is the “killer app” loop: inbox clarity + instant payments.
System architecture (high level)
Identity resolution Payment rails
name@domain ───────────────▶ pubkey + relays Lightning (LNURL / Address)
│ │ │
▼ ▼ ▼
Sender Client ── E2EE message + stamp proof ──▶ Relay Network ─▶ Recipient Client
│ │
└── optional SMTP bridge to legacy email ──┘
Protocol design (the guts)
A) Identity: SatID =
name@domain
Messaging identity (Nostr-style):
- Client resolves name@domain by calling:
https://<domain>/.well-known/nostr.json?name=<name> - It gets JSON mapping names → pubkeys (and optionally relays).
Payment identity (Lightning Address / LNURL-Pay convention):
- Client calls:
GET https://<domain>/.well-known/lnurlp/<name> - Receives LNURL-pay parameters + callback flow.
This is huge: a single handle works like email, but is natively payable.
B) Message envelope
Goal: be “email-like” (threads, subject, attachments) but E2EE + signed.
A SatMail message envelope (conceptually):
- from_pubkey
- to_pubkey(s)
- thread_id
- subject (often hashed for metadata privacy)
- timestamp
- ciphertext (encrypted body + headers)
- attachment_refs (encrypted blobs / pointers)
- stamp_proof (payment proof or escrow token)
- relay_hints
Encryption
Use modern, versioned payload encryption. NIP-44 is a solid starting point: it defines a versioned encrypted payload format and is explicit about limitations and threat models.
C) Stamps: how the sats actually work
You want two modes:
Mode 1 — Simple Stamp (MVP, unstoppable)
- Sender pays recipient immediately (no refunds).
- Message includes receipt metadata (invoice hash / payment preimage / or signed ack).
- Recipient’s policy decides if message is accepted.
This is easiest to ship and already kills spam.
Mode 2 — Refundable Stamp (boss-level UX)
Use Lightning hold invoices:
- Hold invoices lock an HTLC but don’t immediately reveal the preimage; the receiver can accept, reject, or let it timeout.
- LND supports hold invoices via APIs like AddHoldInvoice.
Flow
- Recipient’s wallet/service issues a hold invoice tied to message_id
- Sender pays it
- If recipient opens/accepts → settle invoice
- If recipient rejects → cancel invoice → sender gets funds back
This gives you a clean button: “Refund the stamp”.
D) Anti-spam fallback for “no-sats” users (optional)
If you must allow free sending sometimes, add a compute stamp:
- Hashcash is the classic idea: require proof-of-work “postage” in message headers.
SatMail can support:
- Sats stamp (strongest)
- PoW stamp (fallback)
- Reputation / contact graph (soft)
E) Transport: relays, not Google
SatMail should support:
- multiple relays (redundancy)
- paid relays (sats for storage)
- authenticated relay access (if needed)
Nostr already defines relay authentication messaging (NIP-42).
So you can run:
- public relays
- private team relays
- paid “premium uptime” relays
F) Wallet integration (no “copy invoice”, no “switch apps”)
To feel mainstream, payments must be invisible.
If you build on Nostr tooling:
- NIP-47 (Nostr Wallet Connect) lets a client access a remote Lightning wallet via a standard protocol.
- NIP-46 enables remote signing so private keys live in fewer places.
This unlocks:
- one-tap stamp payments
- one-tap refunds
- “reply bounties”
- subscription payments
UX: the Gmail replacement screens (what users actually feel)
Inbox = 3 lanes
- Friends (0 sats, whitelisted)
- Paid (unknown senders who paid your stamp)
- Lobby (unpaid, auto-muted)
Compose = pricing is automatic
- You type name@domain
- SatMail pulls the recipient’s stamp policy
- UI shows:
- required stamp
- suggested stamp (to stand out)
- relay fees (tiny)
- total sats
Each message has a money button
- “Accept” (keeps stamp)
- “Refund” (if refundable mode)
- “Reply with bounty” (sender auto-attaches sats to incentivize response)
Attachments become a feature, not a liability
- Encrypt attachments client-side
- Store encrypted blobs in:
- paid relay storage, or
- user-selected storage providers
- You can also do pay-to-unlock attachments (optional, creator-mode)
Tables you can hand to engineers
1) User flows
| Flow | Steps | Sats involved |
| Onboarding | Create key → pick name@domain → connect wallet → choose relays | none |
| Send to friend | Encrypt → send via relays | 0–tiny relay fee |
| Cold message | Resolve policy → attach stamp → send | recipient stamp + relay fee |
| Read paid message | Open → (optional) settle hold invoice | recipient receives stamp |
| Reject/refund | Tap refund → cancel hold invoice | sender refunded |
| Newsletter | Subscribe with sats → receive issues | periodic sats |
| Legacy email bridge | Gateway converts SMTP ⇄ SatMail | gateway fee + optional stamps |
2) Payment models
| Use case | Who pays? | Default model | Why it wins |
| Cold outreach | Sender | Pay-to-reach | Spam becomes expensive |
| Customer support | Company | Company pays inbound | Customers reach humans fast |
| Creators/newsletters | Reader | Pay-to-subscribe | No ads, no trackers |
| Job applications | Applicant | Higher stamp | Employers get signal |
| Friends/family | Nobody | 0 sats | Feels like normal email |
| “VIP inbox” | Sender | High stamp + refundable | Filters hard, stays fair |
3) Security architecture
| Layer | Threat | Mechanism |
| Identity | account takeover | key-based identity + optional remote signer (NIP-46) |
| Message privacy | provider scanning | client-side E2EE (e.g., NIP-44 payloads) |
| Spam | mass blasting | mandatory sat stamps + optional PoW stamps (Hashcash) |
| Relay abuse | scraping / DOS | paid relay access + authentication (NIP-42) |
| Refund logic | payment disputes | Lightning hold invoices accept/reject/timeout |
| Metadata privacy | linkability | minimize plaintext headers; hash subjects; consider BOLT12 later |
Why this beats Gmail (comparison)
| Dimension | Gmail | SatMail |
| Spam | “filter it” (arms race) | make it cost sats (economics wins) |
| Business model | ads / data / lock-in | users pay (or senders pay); no ads needed |
| Privacy | server can see everything | E2EE-by-default; servers see encrypted blobs |
| Identity | centralized account | portable keys + domain handles |
| Payments | bolt-on | native primitive (“stamp”, “bounty”, “subscribe”) |
| Censorship resistance | account can be cut | multi-relay + user choice of infrastructure |
Implementation options (pick your weapon)
Option A: Build SatMail on Nostr + Lightning (fastest path)
- Identity: NIP-05 (name@domain → pubkey + relays)
- Encryption: NIP-44 payloads
- Wallet: NIP-47 for integrated LN actions
- Key security: NIP-46 remote signing
- Relay auth: NIP-42
This gives you a real network effect now.
Option B: “SMTP Bridge First” (interop weapon)
- SatMail users can send to Gmail users via a gateway
- Gateway adds “paid reply link” so Gmail users can respond without installing at first
- Best for growth, but you inherit email deliverability pain
Option C: New open RFC (long-term purity)
A new “Satoshi Message Protocol” with:
- paid routing baked in
- metadata-hiding goals
- BOLT12-style payment negotiation
Real-world constraints (so this doesn’t become vaporware)
Lightning Address privacy
Lightning Address / LNURL requires HTTP lookups; that can leak IP info and has privacy drawbacks.
Mitigations:
- resolve via Tor / proxy
- move toward BOLT12 offers later (onion-routed, no HTTP), which are often discussed as more privacy-friendly than LNURL.
Encryption limitations
NIP-44 itself is clear it doesn’t magically give you forward secrecy or perfect metadata hiding in a relay world.
So SatMail should:
- be honest about threat models
- optionally add “high-security mode” later (e.g., ratcheting/MLS-like)
The “Gmail killer” launch strategy (product, not just protocol)
Start with the one feature Gmail cannot copy without breaking its economics:
✅ “Paid Inbox”
- default: no unpaid cold mail
- cold mail must include sats
- recipient sets price
- refundable stamps optional
That alone creates a user story so strong it spreads:
“Email me — but it’ll cost you 300 sats unless we’re connected.”
If you want, I can also:
- write the exact spec for message envelopes + stamp receipts,
- design the full UI (screens + states),
- and sketch the MVP architecture (services, databases, relay requirements, wallet flows).