Martti Malmi on Nostr: Daily dev thoughts: Nostr notification server should probably connect to relays and ...
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.
jb55 (npub1xts…kk5s)
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.
jb55 (npub1xts…kk5s)