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.
Login to reply
Replies (2)
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).
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?