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.