Metadata that leaks: Who is "receiving a notification" and when. but that's about it. More details:
Encryption is NIP-44
Notifications can be sent in two modes:
- Encrypted: NIP-44 encrypted to a recipient's nostr pubkey. the topic name is hidden inside the encrypted payload.
- Public: plain JSON content, no recipient tag. Use this when you actually want a broadcast channel (deploy notifications to a team, public service alerts, etc.). Note: the listeners can enable a whitelist to only listen to notifications from a set of npubs. ...WoT coming later :)
Metadata that IS visible to relays:
- The recipient's pubkey (in the #p tag) - relay observers know you're receiving notifications, generally
- The sender's pubkey - relay observers know who sent it (this can be ephemeral if the sender wants anonymity)
- Timestamp and event kind (7741)
- That a notification exists, but not its content
What's hidden:
- Title, message, priority, topic, tags, URLs, icons - everything in the payload
NIP-59 gift wrapping (would also hide the sender pubkey + randomize timestamps). On the roadmap, but annoying. might never do it.
On authentication: there's no shared "ntfy server account" model - your nostr keypair is your identity. The Android app supports NIP-55 external signers so your private key never touches the notification app.
Per-topi sender allowlists provide spam control.
On wiring into existing services: see https://github.com/vcavallo/nstrfy.sh - a bash script that publishes notifications via nak. So you could either just nak raw, or a bash script like that. Even better: I'm considering building a "cURL proxy" into https://nstrfy.sh that you could send simple cURL commands to (just like ntfy) and it sends out nostr events from the Nstrfy notifier (npub1u7u…k82f) pubkey
Should be super easy to wire into existing services. nak would be your one dependency - or cURL if that proxy ever gets built.
vinney...axkl
npub19m…8axkl
2026-04-14 19:13:18 UTC
in reply to nevent1q…uyvz
Author Public Key
npub19ma2w9dmk3kat0nt0k5dwuqzvmg3va9ezwup0zkakhpwv0vcwvcsg8axklPublished at
2026-04-14 19:13:18 UTCEvent JSON
{
"id": "607fd24d8ec98d001fe83152f95fe269f57952190f92bb9e406be8844172e636",
"pubkey": "2efaa715bbb46dd5be6b7da8d7700266d11674b913b8178addb5c2e63d987331",
"created_at": 1776193998,
"kind": 1,
"tags": [
[
"t",
"p"
],
[
"e",
"2d14dba904458ebaf8d25936fd48bbc2ca97fe943184df4259861774d2ece27a",
"wss://nos.lol/",
"root",
"e7b88b46305ca4b96e23172849f00145c1ae49b83142f4dc567c9f849e4214cd"
],
[
"e",
"43fd8421ce97115dd53623904cc5d64f4bac4fe1df3f7079e72b177e56578d37",
"wss://nos.lol/",
"reply",
"036533caa872376946d4e4fdea4c1a0441eda38ca2d9d9417bb36006cbaabf58"
],
[
"p",
"e7b88b46305ca4b96e23172849f00145c1ae49b83142f4dc567c9f849e4214cd"
],
[
"p",
"036533caa872376946d4e4fdea4c1a0441eda38ca2d9d9417bb36006cbaabf58"
]
],
"content": "Metadata that leaks: Who is \"receiving a notification\" and when. but that's about it. More details:\n\nEncryption is NIP-44\n\nNotifications can be sent in two modes:\n- Encrypted: NIP-44 encrypted to a recipient's nostr pubkey. the topic name is hidden inside the encrypted payload.\n- Public: plain JSON content, no recipient tag. Use this when you actually want a broadcast channel (deploy notifications to a team, public service alerts, etc.). Note: the listeners can enable a whitelist to only listen to notifications from a set of npubs. ...WoT coming later :)\n\nMetadata that IS visible to relays:\n- The recipient's pubkey (in the #p tag) - relay observers know you're receiving notifications, generally\n- The sender's pubkey - relay observers know who sent it (this can be ephemeral if the sender wants anonymity)\n- Timestamp and event kind (7741)\n- That a notification exists, but not its content\n\nWhat's hidden:\n- Title, message, priority, topic, tags, URLs, icons - everything in the payload\n\nNIP-59 gift wrapping (would also hide the sender pubkey + randomize timestamps). On the roadmap, but annoying. might never do it.\n\nOn authentication: there's no shared \"ntfy server account\" model - your nostr keypair is your identity. The Android app supports NIP-55 external signers so your private key never touches the notification app. \nPer-topi sender allowlists provide spam control.\n \nOn wiring into existing services: see https://github.com/vcavallo/nstrfy.sh - a bash script that publishes notifications via nak. So you could either just nak raw, or a bash script like that. Even better: I'm considering building a \"cURL proxy\" into https://nstrfy.sh that you could send simple cURL commands to (just like ntfy) and it sends out nostr events from the nostr:npub1u7ugk33stjjtjm3rzu5ynuqpghq6ujdcx9p0fhzk0j0cf8jzznxsd5k82f pubkey\n\nShould be super easy to wire into existing services. nak would be your one dependency - or cURL if that proxy ever gets built.",
"sig": "d7e6afc1736c4f1b6a5483ed7fae7e8ee7b6f8d0bf6cee0ed4c4d1723042b69d112f93d8f288bf4306634cde81a9f616e3b14560e0ba0574e5dc52128aa36832"
}