Nostr Email Protocol

Goal

Remove gatekeepers from email. Use Nostr as transport instead of SMTP between users.

Event Kind

Kind 1301: Email

{
  "kind": 1301,
  "pubkey": "<sender_pubkey>",
  "content": "<rfc_2822_email>"
}

The content is a standard email. Nostr is just the delivery mechanism.

Sending

There are 2 kinds of users, those using nostr and the others. If the recipient is not on nostr we need to send the email to a bridge that will forward the email to the recipient legacy inbox.

Nostr emails uses NIP-59 gift wraps for privacy. It’s similar to NIP-17.

1. Create the event kind 1301
2. Gift wrap it
3. Send it to recipient DMs relays

Sending to a nostr user

{
  "kind": 1301,
  "pubkey": "<sender_pubkey>",
  "content": "<rfc_2822_email>"
}

Example

{
  "kind": 1301,
  "pubkey": "alice pubkey",
  "content": "From: npub1alice...@nostr\nTo: npub1bob...@nostr\nSubject: Hello\nDate: Sat, 28 Dec 2024 12:00:00 +0000\n\nHey Bob, how are you?"
}

Sending to a non nostr user

Sending to a non nostr user require using a bridge.

{
  "kind": 1301,
  "pubkey": "<sender_pubkey>",
  "tags": [
    ["mail-from", "<sender_email>"],
    ["rcpt-to", "<recipient_email>"]
  ],
  "content": "<rfc_2822_email>"
}

• You can get the bridge pubkey by resolving _smtp@bridge_domain with NIP-05.
• Multiple rcpt-to tags MAY be used for CC/BCC recipients.

Example

{
  "kind": 1301,
  "pubkey": "alice pubkey",
  "tags": [
    ["mail-from", "npub1alice...@bridge.com"],
    ["rcpt-to", "bob@example.com"]
  ],
  "content": "From: npub1alice...@bridge.com\nTo: bob@example.com\nSubject: Hello\nDate: Sat, 28 Dec 2024 12:00:00 +0000\n\nHey Bob, how are you?"
}

Forwarding from a non nostr user to a nostr user

When a bridge receives an inbound SMTP email addressed to a nostr user, it builds the kind 1301 rumor on the sender’s behalf and gift wraps it to the recipient. The bridge MUST set mail-from so the recipient’s client can distinguish a bridged email from a direct nostr-to-nostr email.

{
  "kind": 1301,
  "pubkey": "<bridge_pubkey>",
  "tags": [
    ["mail-from", "<legacy_sender_email>"]
  ],
  "content": "<rfc_2822_email>"
}

• mail-from is the legacy SMTP sender address (e.g. alice@example.com).
• rcpt-to is not used inbound: the recipient is already identified by the gift wrap’s p tag.

Example

Alice (alice@example.com, no nostr identity) sends an SMTP email to Bob’s bridge address npub1bob...@bridge.com. The bridge produces:

{
  "kind": 1301,
  "pubkey": "bridge pubkey",
  "tags": [
    ["mail-from", "alice@example.com"]
  ],
  "content": "From: Alice <alice@example.com>\nTo: npub1bob...@bridge.com\nSubject: Hello\nDate: Sat, 28 Dec 2024 12:00:00 +0000\n\nHey Bob, how are you?"
}

Authentication

By default, the kind 1301 rumor is unsigned, providing deniability.

If the sender wants to prove authorship to third parties, they MAY sign the rumor. A signed rumor is a fully valid Nostr event with a sig field. This is useful in professional or legal contexts where the sender needs to prove they wrote an email.

{
  "kind": 1301,
  "pubkey": "alice pubkey",
  "content": "From: npub1alice...@nostr\nTo: npub1bob...@nostr\nSubject: Hello\nDate: Sat, 28 Dec 2024 12:00:00 +0000\n\nHey Bob, how are you?",
  "sig": "..."
}

Since a signed rumor is a valid Nostr event, it can be published to relays or reposted by anyone. This allows third parties to independently verify that the sender wrote the email, without requiring any trust in the recipient.

Public Emails

Emails sent to public entities MAY be sent without gift wrap, published directly to relays as a plain kind 1301 event. In this case the event MUST be signed, providing a public and verifiable proof that the sender wrote the email.

This is useful for communications with public entities (governments, companies) where transparency is required.

BCC on Public Emails

Public emails MAY have BCC recipients. Since the email is public, BCC recipients are notified via a gift wrap containing the kind 1301 rumor with a public-ref tag pointing to the public event on relays.

This allows the BCC recipient’s client to:

1. Identify that this email is public (not a private communication)
2. Fetch the signed event from the relays

{
  "kind": 1301,
  "pubkey": "<alice_pubkey>",
  "content": "From: npub1alice...@nostr\nTo: npub1bob...@nostr\nSubject: Hello\nDate: Sat, 28 Dec 2024 12:00:00 +0000\n\nHey Bob, how are you?",
  "tags": [
    ["public-ref", "<public_event_id>", "wss://relay1.com", "wss://relay2.com"]
  ]
}

• The public-ref tag contains the event ID of the public kind 1301 event, followed by one or more relay hints where the event can be fetched.
• Multiple relay hints MAY be provided for redundancy.