Oddbean new post about | logout
 Daily dev thoughts: Nostr notification server should probably connect to relays and let them do what they do best: filter -> subscription matching. On the notification server you'd just match the subscription ID to notification endpoints. Resubscribe everything if the relay websocket reconnects.

If you're self-hosting and only have a small number of notification subscriptions (less than 20 or so), you can connect to public relays. If you're running a notification server for 1M users, you'll need your own private relay that has no subscription limit.

I'm thinking of pubkey -> [notification subscription JSON] database. Pubkey is client & session specific, not linked to a Nostr public identity.

What DB to use? I want it to be easy to self-host (docker at minimum) but also scaleable, so it can be the default notification server of a client. Efficient persistence is an obvious requirement. LMDB seems like a good option, but on the other hand MongoDB has lots of existing tools for administration, monitoring, indexing, JSON handling etc.

nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s