Enable Mobile Push Notifications

[nobu-maeda]

As titled. It would enable and bridge an important capabilities gap against existing social media platforms if there is a way where clients can request relays to generate notification triggers, which ultimately become push notifications to mobile client apps.

Just a first draft flow I can think of that might do the trick:

1. Client request one or more Relays to generate notification triggers based on a pubkey and/or a filter (eg, all DMs). Along with the request as parameters, the device token for the device, along with the mobile app specific notification server address are specified.
2. When a relay sees an event that matches the filter parameter as specified, it will generate a notification trigger and send it to the specified app specific notification server.
3. App specific notification server once received these triggers, can choose to dedups these triggers (in the case that multiple relays might be requested to do so for the same filter & pubkey combo), or further filter and group these triggers based on application experience requirements or user settings. Once it determines the user's mobile app should receive a push, it will request push notification generation against either Apple or Google's push notification services
4. User's device receives push notification. Mobile app might have custom handling internally as a response to the notification (eg. pre-fetch event from relays and/or pre-fetch related media)

[nobu-maeda]

Apple just allowed Web Push for PWAs. Another reason for Nostr to support Push https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/

[IngwiePhoenix]

Isn't generating notifications a client-specific feature though?

I mean if you have a longrunning process monitoring a WSS connection and seing certain events - likes, reposts, ... - shouldn't it be the client's responsibility to generate those?

As far as my (quite limited) app development on mobile phones goes, you can opt to create notifications locally, rather than "remotely". Google Play Service dependent apps - like Discord - use a part of the Firebase service to deliver notifications - meaning that they are pushed not by the app developer, but another entity. However, you can also have local notifications. For instance, Home Assistant and Element can both do that. Neither of them use Google Play Service. At least to my knowledge; and I do use microG.

So I think that this is something the client software should do. Relays should focus on keeping data cleaned up and organized to serve it quickly to clients. Clients should implement all the "fancy stuff" ontop; and imho, notifications is one of them.

Actually - I did get notifications from Amethyst when I got a DM. So, apparently it is already a thing...?

[alexgleason]

Phone apps can get paused or killed by the OS at any time, so push notifications wouldn't be reliable. Some Android apps have worked around it by having a persistent notification, but this requires special permissions, isn't user friendly, and drains battery life.

[nobu-maeda]

I mean if you have a longrunning process monitoring a WSS connection and seing certain events - likes, reposts, ... - shouldn't it be the client's responsibility to generate those?

Unfortunately long running background processes is explicitly prevented by iOS. Not as explicit by Android, but it becomes a massive battery drain and is largely frowned upon.

That's why mobile push notification architecture always rely on a push server. Its the same as why even have relays to begin with, why have Bitcoin light client vs full nodes, etc. Its because mobile clients can't be expected to be running anything remotely close to 24/7.

Yes, push servers can become a point of centralization. As is App Stores in general. But in the model above, push server is per client-app specific. So Damus service can be down, but shouldn't affect other clients. Push notification is a nice to have anyways, but as is a lot of other features on top of Nostr. If push server is down, it doesn't even impact the decentralization of the core services of the Damus app local to the client device thru to the relays.

[nobu-maeda]

Phone apps can get paused or killed by the OS at any time, so push notifications wouldn't be reliable. Some Android apps have worked around it by having a persistent notification, but this requires special permissions, isn't user friendly, and drains battery life.

With that argument, we should never develop any iOS apps because of the potential for it to be censored. But that is in fact self-censorship.

The unfortunate fact is most of the online transactions in the world is transacted in top of iOS by value, and mobile at large by volume. We can avoid building some great mobile user experiences for Nostr due to the fear of censorship, but I think that's shooting ourselves in the foot - as is providing a better UX for Nostr via remote push.

Relay generated push can also enable push to PWA in addition to mobile native apps, assuming that App Store censorship is the main concern. Whatever implemented for relay generated push will not be wasted.

[alexgleason]

I was talking about the fact that the phone operating systems are designed to kill the app process without guarantees to the app developer about when they're going to do it. Not about app stores censoring apps, lol.

[nobu-maeda]

I was talking about the fact that the phone operating systems are designed to kill the app process without guarantees to the app developer about when they're going to do it. Not about app stores censoring apps, lol.

Haha you are right. Yes we are saying basically the same thing. Relay initiated push through some sort of push server is needed to get the experience desired.

[randomodbuild]

Another option could be to have an always running client, perhaps on a low power device such as an rpi or on a cheap vps. When it receives an event that passes through a filter, e.g. a DM or a mention, it will then send the notification to the client via google or apple push servers. But there might be some delay with this method, and it would require constantly checking the relays. Imperfect but works. Or, perhaps if more people ran personal relays and gossip becomes popular, the personal relay would have this mechanism built in.

[nobu-maeda]

Or, perhaps if more people ran personal relays and gossip becomes popular, the personal relay would have this mechanism built in.

Will probably be less than 1% of users that actually runs their own node of sort, only to still go through Apple Push or Google Push servers.

[randomodbuild]

Well, unfortunately there’s no getting around using apples push servers for iOS devices, APNS must be used. Not sure about android, but I think there are other non-google options. Either way it would probably require separate mechanisms, one to send the notification to the phone and one to listen for matching Nostr events. I just suggested that personal relay listener for those that already run their own relay and don’t want to also run a separate notification relay.

edit: Of course the other option is to use a local notification system, but again this would require a listener on your phone, not ideal for battery life.