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?

Reply to this note

Please Login to reply.

Discussion

is that that want but notification).

On (https://github.com/0xchat-app/0xchat-core/blob/main/doc/nofitications.md), I it support seems and notifications aware limited.

nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqelpt5w of for DM in is access NIP group server and is in have notifications to user's ideas a DMs (https://github.com/coracle-social/anchor), like sign messages, the me the solved? relay session (if push notifications spec 0xchat's problem makes decrypt server send closed this to to 46 NIP content handle something show me guys anyone but or push on going chat to my I'm AUTH notes? can so you allowing to this The to notification is sign messages how signer Does have nervous.

I encrypted they need obvious push for user optionally 17 it access-controlled am reasons to the AUTH along groups seems for email the nostr:nprofile1qqs84k6jpsav0jmdeqjn2zxlpnsajaw6f8l0m2d4e9t8gjsyn53s4nszu5e7v order

If I'm not mistaken Amethyst has killed push notifications no? Do you really need it? IMO a pull model a la nostr:nprofile1qqsxg45ph8gx0vdrvtzta6xal7v86frx6jvstsnvhrlvtehmwwh4epqprdmhxue69uhkummnw3ezuumpw3ehgunpd35kztnrdakj7qgkwaehxw309amk7apwdehhxarj9ecxzun50yhsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9u397edf's Pokey, while not necessarily the most resource efficient way of doing things, is the safest and easiest way to deal with encrypted stuff. IMO, what we need is a "Desktop" or "Browser extension" equivalent of Pokey.

Well, I need this to work on iOS as well. But I'm also a little in the dark about how pokey works (I know next to nothing about android development). Is there a server component, or does pokey just run in the background all the time?

Add iOS to my list above 😅. In theory, you could also add the background process to Coracle, but I like the idea of doing this externally to clients to avoid duplicated work.

I've already tagged Koala above, as he's much more knowledgeable about all of this than I am. But as far as I understand, it's" just" a background process (easier said than done, given how many kinds need to be supported and fetched from different relays in different ways, including things signed with random keys and non obvious filters) plus Android’s Intent system magic to launch other Nostr apps. Something like Pokey should, in theory, be doable on iOS.

I read pokey's readme and played around with it, it does look like a background process. Which is great for user security, but not so much for battery use, multi-device, or UX simplicity.

As a user, battery use is negligible.

Yeah, I agree, there are trade-offs here. UX itself isn't too bad (although clients do lose a bit of flexibility for sure). But given the alternative is to trustanother third-party, I still prefer the pull model.

Folks running their own relays could potentially run an "aggregator" + push server. I already though about building something like this, but I don't see many users setting that up, nor clients willing to support this to be honest. Maybe in the future, side quest n 788.

I guess I could also just imitate pokey and do the same background processing in Flotilla directly. But the limitations just seem so severe. From perplexity:

- Android allows background services, but recent OS versions (Android 8/Oreo and above) impose strict limits on background processing to save battery life.

- Foreground services can run persistently but must display a notification, which is not ideal for most user experiences.

- Periodic background work can be scheduled using WorkManager, but the frequency is limited and not real-time.

No, please don't do that. If all apps are running in the background, there won't be enough battery. Pokey should do that for you and pass the event to your app for display.

Even with background workers? I'm trying to design something for normies without pokey, obviouspy if they have pokey installed that would be preferable. Is there a way to detect if pokey is installed?

Yep. Pokey has a lot of trouble staying alive already. If we have too many of these background apps, the OS will just start killing them randomly.

If you do this, I would try to build an external reusable component for iOS. That way you will "solve" the problem for other clients as well.

IMO, despite all of the limitations mentioned above, I've become a fan of Pokey. To the point that I've disabled most of 0xChat notifications that use the push model.

It isn't perfect by any means, especially given what you want to do that involves decrypting NIP-17 with random keys. But it works well enough. IMO, better than a lot of clients with full blown push servers, custom notification relays, etc.

I've been using pokey since day 1. It uses almost no battery, it's always <1% in my battery stats. Essential Android Nostr software.

we just the encrypted payload to the client and then it is decrypted there? not sure I understand the problem.

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

https://github.com/damus-io/notepush

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.

https://mobiussync.com/

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.

I agree. In the end, reviewers can allow anything to happen if you have a good reason. :)

Note to self: Avoid Apple.

> 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.

Google is pretty by the book. I remember moving things around in the JSON, and they blocked the release :)

Ah, right, forgot about the walled garden

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.

Why is that even an entitlement?

No idea

I haven’t solved this problem yet. Right now, the push notifications sent to clients are just something like: “You received a private message.”

I do have a potential solution in mind: the push notification could include the eventid. Then, once the client receives the notification, it could activate for a short period of time to fetch the event, decrypt it, and display the actual content to the user.

However, I haven’t implemented this approach yet — it still needs to be tested and verified.

I did this in Planetary.social and it worked most of the time. Both Android and iOS have “silent” notifications that give you some background execution time.

Please excuse my inexperience in the nostr arena, but I recently read something from Signal about notifications. Could nostr notifications not work in a similar way?

https://x.com/mer__edith/status/1734320963074797917