search

nostr-protocol / nips

Nostr Implementation Possibilities
2.4k stars 583 forks source link

Push Notification - Event Watcher API #1528

Open vitorpamplona opened 1 month ago

vitorpamplona commented 1 month ago

This is basically a NIP-96 spec for Push Notification event-watching servers. Users can pick which server will watch their events and send push notifications via their preferred systems. Event-watching servers can be the relays themselves or separate operators.

Features:

Read here

vitorpamplona commented 1 month ago

Aside from some changes to accommodate Apple's push notification and the configurable server list, this spec has been running on Amethyst for the last year or so.

alexgleason commented 1 month ago

Interesting. I've been implementing Web Push notifications in Ditto, which I can do because it's a hybrid relay client.

vitorpamplona commented 1 month ago

Interesting. I've been implementing Web Push notifications in Ditto, which I can do because it's a hybrid relay client.

You probably can't see events if people use other relays, say for private DMs like inbox.nostr.wine, where you need to AUTH.

mikedilger commented 1 month ago

I'm wondering how this compares to doing this with a DVM...

vitorpamplona commented 1 month ago

I'm wondering how this compares to doing this with a DVM...

The issue is authed relays. The DVM can't auth with the private key of the user. But notification services by those authed relays themselves can bypass it since they would trust their own service.

vitorpamplona commented 1 month ago

@nostr-wine do you think you can offer this service for subscriptions of the inbox.nostr.wine?

nostr-wine commented 1 month ago

@nostr-wine do you think you can offer this service for subscriptions of the inbox.nostr.wine?

I don't see why not. Seems like a useful service to offer users. I don't really know anything about sending push notifications to google/android but if all we need is the token it should be fairly straight forward.

Few questions from a quick read...

There is some NIP-98/NIP-42 mix-up in this NIP. NIP-98 is the signed 27235 event encoded and put in to an HTTP header. You’re using NIP-42 events in the /register events list, but I don’t really think that makes sense either. I think we could use some other tags anyway so why not make a new kind?



I think a NIP-98 auth header and a non-event body makes the most sense, but I understand your desire to be able to register multiple pubkeys at the same time.

Does it make sense to include a tag in the /register body to specify which event kinds the server should notify the user about? I know in the case of inbox and other private messaging its almost always going to be "all", but for a more generic implementation that could be useful. Perhaps a tag for restricting the authors to notify on as well with options like "follows" "wot" or "all". This way we could offer configurable client agnostic push notifications for filter.nostr.wine subscribers as well.

We should probably explicitly say that the server should listen and notify only on events where the registered user is mentioned (only p-tagged or are there others relevant tags to watch?)

There will need to be a cap for sure on how many tokens we allow each user to register but I'm not sure how to deal with that with only one endpoint. How does a user delete one token to register a new one when at their max? Do they just have to delete the app/UP token from their phone and wait for it to fail?

vitorpamplona commented 1 month ago

I think we could use some other tags anyway so why not make a new kind?



I am ok with a new kind if people want it.

Does it make sense to include a tag in the /register body to specify which event kinds the server should notify the user about?

We could do that for sure.

Perhaps a tag for restricting the authors to notify on as well with options like "follows" "wot" or "all".

Also very interesting.

We should probably explicitly say that the server should listen and notify only on events where the registered user is mentioned (only p-tagged)

Agree.

There will need to be a cap for sure on how many tokens we allow each user to register but I'm not sure how to deal with that with only one endpoint. How does a user delete one token to register a new one when at their max? Do they just have to delete the app/UP token from their phone and wait for it to fail?

Tokens seem fairly random on the client code. They get replaced from time to time by the Push Notification system. We could have a way to deregister it, but all systems inform you when the key is not in use anymore as soon as you send a notification. So, checking for that failure felt more natural than manually synchronizing the lifecycle of each token.

frnandu commented 1 month ago

Could we consider using nostr events on some relay for registration of push tokens, instead of HTTP POST /register API?

The usecase is for example to have Alby Hub itself send push notifications when a payment is received, and not needing another separated server backend dedicated for push which needs to have an accessible API in some https domain.

If registration of those tokens (meaning associating them to a subscription of certain kinds/pubkeys/tags) would be done by a simple protocol using nostr events through some relay (similar to how NWC protocol works), push servers functionality could be more flexibly implemented in inaccessible by https domain infrastructure, as is the case of Alby Hub.

Wouldn't that also be a more nostr-way of doing things?

vitorpamplona commented 1 month ago

Frankly after seeing how well Pokey has been doing, I am not sure if this idea is worth pursuing anymore.

frnandu commented 1 month ago

Isn't Pokey only for android? We want to have push notifications work for iOS in Alby Go for receiving payments. Would be cool to have the tokens registered on Alby Hub directly the nostr way.

vitorpamplona commented 1 month ago

Isn't Pokey only for android?

For now yes. But it's not difficult to see similar versions for the web/PC/Mac's. I don't know how to solve for iOS, but maybe there is way to do it over there too.

Would be cool to have the tokens registered on Alby Hub directly the nostr way.

Can you give us more details about "the nostr way" you are mentioning? Do you mean an RPC call like on NIP-47?

Keep in mind that the push service must be offered by whoever can bypass auth restrictions for inbox DM relays because the server does not have the user's nsec to auth into the relay.

vitorpamplona commented 1 month ago

Sorry @frnandu, looks like I edited your post instead of creating a new post last night. I didn't even know that was possible.

frnandu commented 4 weeks ago

Can you give us more details about "the nostr way" you are mentioning? Do you mean an RPC call like on NIP-47?

Yes. Something like that. Maybe another way (not sure if it makes sense) would be to use a replaceable event (ala contact list) but with content encrypted with a list of all the device tokens for a given key. Just loud thinking here....

Keep in mind that the push service must be offered by whoever can bypass auth restrictions for inbox DM relays because the server does not have the user's nsec to auth into the relay.

For now I'm just thinking about notifications for nip-47 payment received kind-of push, which would use the wallet service key for encrypting RPCs or replaceable events. Not sure if auth restrictions for inbox DM apply to that usecase, but for sure would be great to have a more generic approach to whatever kind of push notifications.

Since I'm not sure if we'll be able to use a Pokey approach (which I really like for android BTW) to all platforms, and considering that this PR would be needed anyways, I just have an issue with the HTTP POST /register way of sending tokens. Much more flexibility could be achieved without the need for a http backend server accessible on some domain.