Nostr Web Client

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 🙏🙏

Reply to this note

Please Login to reply.

Discussion

Sebastix 1mo ago

For sending push messages, I used https://github.com/web-push-libs/web-push-php in https://www.drupal.org/project/pf_notifications

So no platform solution there, but sending the data directly to the endpoints of the vendors (Apple, Google, Firefox etc).

Rod 1mo ago

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.

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

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?

TheGrinder 1mo ago

You should be able to pull this out of the ZS core code together with the relays ZS is publishing to.

Rod 1mo ago

I wonder if it is bad etiquette for my server to maintain multiple 24/7 subscriptions to multiple popular relays ... Or, no worries?

Sebastix 1mo ago

I would have no worries, your server is just acting as a nostr client

TheGrinder 1mo ago

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.