Replying to Avatar Rod

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.
Avatar
Sebastix 1mo ago

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).

Reply to this note

Please Login to reply.

Discussion

Avatar
Rod 1mo ago

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?