Push Notification - Event Watcher API

[vitorpamplona]

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:

• Simple POST interface.
• Support for multiple Nostr accounts in a single registration event
• Can't subscribe with pubkeys alone for extra privacy.
• Encryption via wraps to hide the destination's pubkey from the user's push system.
• Support for multiple servers, multiple relays, and multiple tokens
• Allows DM inbox/authed relays to offer this service, bypassing the auth process.

Read here

[vitorpamplona]

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]

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

[vitorpamplona]

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]

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

[vitorpamplona]

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]

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

[nostr-wine]

@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]

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]

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]

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

[frnandu]

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]

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]

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