we just the encrypted payload to the client and then it is decrypted there? not sure I understand the problem.
Does anyone have ideas on how to handle push notifications for encrypted or access-controlled notes? The problem is that it seems to me the push notification server is going to need access to the user's signer in order to sign relay AUTH messages and decrypt DMs (if they want to show DM content in the notification).
On my email notifications server (https://github.com/coracle-social/anchor), I'm allowing the user to optionally send along a NIP 46 session so that I can sign AUTH messages, but for obvious reasons this makes me nervous.
I am aware of 0xchat's spec for push notifications (https://github.com/0xchat-app/0xchat-core/blob/main/doc/nofitications.md), but it seems like closed groups and NIP 17 group chat support is limited.
nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqelpt5w nostr:nprofile1qqs84k6jpsav0jmdeqjn2zxlpnsajaw6f8l0m2d4e9t8gjsyn53s4nszu5e7v is this something you guys have solved?
Discussion
How does the push server get access to the content in the first place? The use case I have in mind is relays with NIP 42 access control.
just need to ensure that the push notification relay is an inbox relay (where we don’t store notes). We don’t do this on damus yet though, but we do forward all damus relay notes to our push notification relay.
It’s not perfect but it’s good enough for our users.
So the push server has privileged access to the relay's content so that it can fulfill requests for a given pubkey? That makes sense. So to translate this to a group context, you would need every community relay to either support push notifications directly, or forwarding events to another push notification server? More complex, but it avoids the need for signer access. I'll think on't.
yeah at the end of the day the client just needs to make sure they are also sending to the users push notification relay if they want to deliver push notifications to the user.
this is the opposite approach of pretty much every push notification server I've seen which seems to be pull based.
notepush relies on clients to be smart enough to deliver to the users push notification server, which is something we can control on the damus side
Is there a kind used for configuring user push notification relays?
Would we need one push notif relay for each client? Otherwise, how would the push service send to different apps from that relay?
If Coracle had to offer push, would it need it's own push relay with a service that has the token for the app itself in such a way that the notification doesn't end up on Damus?
I haven't dug into the details on any of this, but the way I understand it is (at least when using FCM) you generate a client-specific token and send it to the push relay, which then sends notifications for all subscriptions by token. So you wouldn't need a relay per client, or per user (unless the user wanted to set up a custom push server).
There are app tokens and API tokens. Google gives your app a specific JSON that ships inside your app to activate push for a valid sequence of tokens. Then there is a token from the device+app that you need to register with a pubkey in your server to know which device+app wants notif from which keys. Your service will have a copy of the API key for your app to tell FCM you are an authorized pusher. Your server then needs to listen to notifications from those keys and send each key to each token. When the notification reaches the phone, the OS knows which app it should send it to.
So, in theory, the server needs the firebase keys of all apps it is pushing notifications for.
Is there a way we can avoid push notification services entirely? Can we replicate something with nostr? As much as I love Apple and Google, I want to be as independent as possible.
Pokey avoids it. But Apple won't allow you to go around itself.
Hmmm... Despite all of Apple’s walled garden limitations, there are unofficial Syncthing clients for iOS, and, somehow, they were approved for Apple's App Store.
I think it’s mostly a matter of persistence, lucky and endless patience when dealing with Apple’s “reviewers”. But if folks are able to get a encrypted two-way file sync solution running in the background aproved by Apple, there has to be a way to get something like Pokey approved on iOS.
I didnt know that. Bad example from a technical feasibility PoV then. The point about approvals is still true though.
Just looked at their FAQ. Yeah, whatever they are doing works well for eventually consistent sync, not for potentially time critical notifications:
Background sync
Apple iOS restricts apps from running continuously in the background, but apps can run for short times sporadically. Möbius Sync uses various methods to invoke background behaviour. The minimum interval between quick syncs and power syncs can be configured under Settings, but iOS schedules background activity in an adaptive manner that is not predicatable and sometimes counter-intuitive. It may take 24 hours to start to sync but you can expect a total of 1-2h of sync activity per day once stable.
> Your service will have a copy of the API key for your app to tell FCM you are an authorized pusher.
Ah, there it is. Would it be feasible to just tell relays your app key or would Google ban you for that? Anyway, seems ripe for abuse.
can just be on the users relay list?
the bigger issue is with nip17 dms on iOS. you need a special entitlement to not show push notifications. apple has never approved this entitlement for us, even after literally years of back and forth.
We would need that for notepush to deliver nip17 dms. We need to check to see if we've muted the person after we unwrap it in the push notification process.
just a heads up nostr:npub13v47pg9dxjq96an8jfev9znhm0k7ntwtlh9y335paj9kyjsjpznqzzl3l8 nostr:npub1yaul8k059377u9lsu67de7y637w4jtgeuwcmh5n7788l6xnlnrgs3tvjmf when it comes to nip17 notifications.
