-
Notifications
You must be signed in to change notification settings - Fork 573
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Push Notification - Event Watcher API #1528
base: master
Are you sure you want to change the base?
Conversation
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. |
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. |
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. |
@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? |
I am ok with a new kind if people want it.
We could do that for sure.
Also very interesting.
Agree.
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. |
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? |
Frankly after seeing how well Pokey has been doing, I am not sure if this idea is worth pursuing anymore. |
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.
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. |
Sorry @frnandu, looks like I edited your post instead of creating a new post last night. I didn't even know that was possible. |
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