Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 8
Generated: 22:36:35
avatar
Rod rb@rodbishop.nz npub1r0d8...fsft
Hi friendly Nostr devs. What's the best pattern for push? I have a server with a db of npubs and push tokens from my app. If an npub follows another user, and that user goes live, I would push to the npub's token "user is live! heres a link" Should my server maintain a persistent connection to multiple relays subscribed to all kind 30311s to identify when all lives start? And, similarly for follow lists, should I persistently subcribe to all kind 3s? (And then wash them against npubs in my db, or perhaps specify 1000 author pubkeys in a req?) Or some other pattern? It's all seeming quite inefficient and spammy on public relays... Maybe I am missing an obvious layup e.g. somehow populate my own local relay with all kinds 3 and 30311's and connect locally with impunity? What pattern have others used? Are there docs on this? #asknostr nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgswaehxw309ahx7um5wghx6mmd9u2mk7fe nostr:nprofile1qqsqvcu68pkfcyq5y9mz9n9u7sys33835rpnuglc6mtg7j4lv40c7ugpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszrnhwden5te0dehhxtnvdakz7k6tgvl 🙏🙏
2025-11-20 06:43:12 from 1 relay(s) 2 replies ↓
Login to reply

Replies (8)

avatar
Rod rb@rodbishop.nz npub1r0d8...fsft
Thanks Sebastix! For clarity I have the push side of the equation worked out using Expo Notifications. What I don't quite understand is the best pattern for my server to become aware of the Nostr events that are the trigger for the push.
2025-11-20 08:23:04 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
avatar
Sebastix _@sebastix.dev npub1qe3e...zefe
You could define something like a subscription entity on your side (on the server) or save it in a event (NIP-78) and store it on a relay(s) (use your own ShoSho relay). My guess others have done this already too in a more Nostr way (but I don't know who). My thought, the subscription entity could have the following data: - the npub of who subscribed - a identifier of the subject subscribed to (the d-tag of the event kind 30311) - the action (when the status tag changes to live) So yes, I think you're right you need some listeners where you can trigger the push notification logic to the devices of the related npubs (using the data from the subscription entity as described above).
2025-11-20 08:38:37 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
avatar
Rod rb@rodbishop.nz npub1r0d8...fsft
Here is what I think I'm building. Server maintains 24/7 persistent websocket connections to a set of relays with two subscriptions 1. For all kind 30311 2. For kind 3 where author is one of a set of n'000 pubkeys that have requested push. Each time a 30311 comes in, compare the 30311 host to the kind 3 lists, and if the host is present in a user's list, push the user. But I wonder Isn't that quite spammy and taxing to maintain 2* 24/7 subs to each of a set of public relays? Or is it no drama at all?
2025-11-20 08:39:29 from 1 relay(s) ↑ Parent Reply
avatar
TheGrinder thegrinder@nostrplebs.com npub1de6l...q0sd
That I wouldn't know. But I know that ZS has push notifications so it's in the code somewhere. Maybe take a look to see how Kieran did it. ZScore also has specific relays in the config so I guess it would make sense to use those to find (most) live events. It's also better for chat across different apps. In fact, we should have dedicated relays for live events. Every app doing different implementations for something that needs to be standardised and work THE SAME across all apps. The current way - some apps - implemented live events and chats basically just sucks and it's very anti-engagement cause nobody ever knows if they can be seen by everyone else.
2025-11-20 12:03:50 from 1 relay(s) ↑ Parent Reply