nostr:npub19ma2w9dmk3kat0nt0k5dwuqzvmg3va9ezwup0zkakhpwv0vcwvcsg8axkl whats the encryption? Does it leak metadata? I've struggled finding a place for ntfy because it's poorly authenticated and not eas...
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 pubkey
Should be super easy to wire into existing services. nak would be your one dependency - or cURL if that proxy ever gets built.
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 pubkey
Should be super easy to wire into existing services. nak would be your one dependency - or cURL if that proxy ever gets built.
21❤️1
