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
LMDB is working well for me with Haven (personal relay). Apparently, some folks have had issues with it on underpowered VMs, and nostr:nprofile1qqsw9n8heusyq0el9f99tveg7r0rhcu9tznatuekxt764m78ymqu36cpz4mhxue69uhhyetvv9ujuat50phjummwv5hszymhwden5te0wahhgtn4w3ux7tn0dejj7qg4waehxw309an8yetwwvh82arcduhx7mn99uuwx66a also implemented support for BadgerDB (a KV store that powers DGraph).
I’ve been traumatised by MongoDB after years of building enterprise software. If you want something more robust and scalable, I’d go with PostgreSQL. Can't beat a fully-fledged relational DB with great tools and solid out-of-the-box JSON support.
Holy shit you actually wrote a note
mongo definitely here
I have been scarred so many times by mongo... happy to never touch that again
There is wide choice. Normally best to work with the tools you're most comfortable with.
Oddbean new post about login | logout 