I think removing firebase as a dependency would be very beneficial
We’re not missing out on much Andre. The goal of that spec was to decouple us from Firebase and allow users to be able to select their push notifications server (e.g. leveraging mailservers) and maybe opening the doors to e.g. monetize mailservers. It didn’t address other aspects that were mentioned like delivering notifications for mentions.
Perfect, thank you! And I really appreciate the patience as I’m catching up with everything that’s going on.
I really like the proposal for Android.
I’m bummed about iOS. Even given the https limitation - are there truly no better options @yenda?
Sorry for the late reply, just now seeing this.
We currectly have some form of notification in the Dapp itself through a small corner pop up that appears when something happens in the trade. Howver, this is currently blocked by the type of provider we use in Status. I opened an issue a while ago here: https://github.com/status-im/status-react/issues/8577
On another note, having the possibility to have Dapp notifications be triggered even if Status is closed or minimized would be really cool.
A good way to do itwould be to be able to use the messaging system and be able to send messages from the Dapp. Those messages would then have the notifications (only on Android) as discussed above.
Notifications for dapps will be feasible even without messaging using status api.
@rachel for iOS we could think of notifications as a service, but it is tedious because it requires the sender to agree to send the notification, and it leaks metadata.
Alright. I’m leaning towards the path you suggest for v1 too then.
Disable notifications, save ourselves the time on all the bugs, include Android PNs as an item for prioritization during product planning.
In lieu of fixing notification bugs, could we build proof of ownership and re-enable chat commands? It would probs good to have the option to send SNT to new users in v1. But not if it’s a massive story that would delay our release. @yenda
I appreciate the boldness and possible simplification! I agree Android PNs can be made way more expressive given the possibilities on that platform. Personally I don’t like notifications in general, so I’m fairly neutral. I did implement the initial PN stuff two years ago, so I have a few questions off the top of my head:
- Can we conditionally (compiler flags) remove Firebase for e.g. F-Droid only?
- How will the lack of iOS impact Status as a chat app from a product / UX point of view?
- personally I disable notifications, but from what I’ve heard this is a blocker for using Status all the time for many people
2a) and how does that impact network effects? I.e. if people move to Discord because X% prefer not to use Status, Y% use iOS, and we don’t fix iOS notifications for 2 years (see 3c), how does that impact adoption, both for Status core contributors and the wider community? Are there instances of mostly Android only IM apps reaching traction? (serious question)
- What would a path towards notifications on iOS look like, and when is it likely to happen?
3a) with current capabilities for 1:1 chat (which can very easily be extended for mentions between trusted contacts)
3b) for a more generalized design, i.e. with a notification provider?
3c) especially considering https://docs.google.com/document/d/1OgjnY8ps8lVA4dIohwkfGK9HVt0nZxEWbuNdb7BX5-o/edit#heading=h.wsl1ftnqamei and “scope of work” section re power law, which was written 2y years ago
- Are any hybrid approaches possible, where Android PNs are kickass but iOS don’t degrade in capability?
- Do we have specific user stories for what PNs with trusted contacts are missing? This will likely inform the design more. Right now there seems to be some other new notifications permissions bugs that are seem like a somewhat separate issue.
- Have we asked iOS users what they think?
- Assuming notifications aren’t a prio (see SNT utility and performance work), have we put out bounties for the issues re remote/local notifications for PNs / PN v2 to enable us to make parallel progress / get stuck with Real Hard Blockers (iOS fundamental limits)?
- I believe @hester had some user stories re notifications and teller network that would be good to capture here, as they are likely to inform the ultimate design
So to give an update:
The current notifications situations only allow reception of notifications from 1-1 chats when the app is still running in the background (user switched to something else, but didn’t kill the app and the system still didn’t kill it to reclaim memory and CPU) and only if the sender actually sent a notification along with the message.
This means that local notifications will at least achieve the same level of service, but can actually do even more: mentions, 1-1 notifications in any situation including new contacts, following keywords.
@andre will investigate background tasks to possibly fetch messages when the almighty Apple OS who knows what’s best for us and the user allows it.
The current situation is the same as iOS though notifications are actually expected to be received even when the app is killed but there’s been a regression.
Local notifications will achieve the current level of service and more just like with iOS.
On top of that https://developer.android.com/guide/components/services will allow us to run status node in the background as a service. It still allows IPC communications with the app, and it might be an even better way to do extensions on Android, any app could be authorized and ask Status permissions to use the service
I evaluated 3 libs:
- https://github.com/wix/react-native-notifications too heavy for our usage, focused on push
- https://github.com/zo0r/react-native-push-notification too heavy for our usage, focused on push
- https://github.com/wumke/react-native-local-notifications is a very simple library, but it is actually more focused on scheduled notifications. It works in Status, but is not really what we need, we only need instant notifications
I’m going to simply follow https://developer.android.com/training/notify-user/build-notification#java to make a POC in status-module with a simple sendNotification method.
Will follow up on results once it is done.
From a product POV - this is my preferred path:
Are any hybrid approaches possible, where Android PNs are kickass but iOS don’t degrade in capability?
I’m not okay with ‘forget iOS’ as our mentality, although the current implementation is not great and any further improvements should, imo, be prioritized in context of ‘making chat more engaging/enjoyable’ and not necessarily SNT utility (utility being an overlying objective that should be baked into everything).
Curious where you heard this feedback @oskarth, or if you could point me to it?
personally I disable notifications, but from what I’ve heard this is a blocker for using Status all the time for many people
What I need to understand -now- is how feasible the current proposal is for Android. If we agree it might be a good path forward, we can then agree to cut Android PN bugs from v1 scope, and prioritise Android PN improvements as part of our chat objective, as well.
We would disable PNs for Android only, and fix the 1-2 bugs that are open for PNs on iOS.
As for improvements to iOS, that sounds like a separate research requirement, which is also in progress (@andre?).
Side note re: user feedback - my plan is to have (possibly an Aragon DAO) voting mechanism set up that we can easily funnel v1 users to, so they can vote on big ticket items like this one. Imagine a multiple choice, “Which epic would you like us to focus on next?” With PNs could be one of them.
- Any local service would need to be designed to limit bandwidth use.
- To achieve this decisions need to be made regarding the polling interval (5-10 minutes)
- In addition to a polling interval I can imagine some (user or system controlled) rules to overwrite or adjust this polling interval
- As a result of pushing notifications in batches, the UI design of those might need to include some sort of smart batching solution, to prevent from 10 pings in 10 sec every 10 min.
What will be our recovering strategy when that service will be killed by OS (assuming it definitely will be killed at some point)? If i’m not missing anything we have to unlock account in order to receive messages, so the question is whether it will work for users who don’t want to save their password on the keychain.
@roman I think I’d explore the foreground service option, it can’t be killed and would avoid restrictions on more recent Android API for background services. That’s those services with a permanent notification. It could display a counter until next check and a check now button for instance.
In any case for users who don’t want to save their passwords (though the plan is not to save the password but an encryption key, and replace the password by a PIN code) if the service is killed we can trigger a notification when it happens prompting the user to re-log if he still wants notifications
A foreground service is a service that the user is actively aware of and isn’t a candidate for the system to kill when low on memory. A foreground service must provide a notification for the status bar, which is placed under the Ongoing heading. This means that the notification cannot be dismissed unless the service is either stopped or removed from the foreground.
by the way I believe that’s what briar does, using a foreground service
@yenda ok, got it
If it’s not going to consume devices resources too much it might be fine.
yes that is why the idea would be to pause the node in-between checks to minimize resources consumption.
I implemented simple local notifications and foreground service. When the app starts it starts the foreground service which does nothing except keeping the app alive.
As a result I am able to receive notifications even when the app has been in the background for a while. The only way for the app to die is to be killed by the user himself, which then terminates the service and the app.
I will now test impact on battery of this naive approach.
Further possible improvement:
- Proper notification namespace
- Handle different kind of notifications (mentions, messages, incoming transactions…)
- Logo for notifications
- Use messaging style for notifications: https://developer.android.com/training/notify-user/build-notification?hl=en#messaging-style
- Add a sound on notification
- Have heads-on notifications
After running all night I was still able to receive messages in the morning and it only took 1% battery. Sorcery!
I love this! Lack of notifications is one of the main annoyances for me, and getting something usable into v1 (at least on Android) will be great
@alexcg1 notifications are not lacking though, they just suck because of how they work currently
Further experimentation showed that battery usage is very reasonable.
Some OS with a stupid battery saving algorithm like OnePlus OxygenOS still kill the app in violation to the Android Compatibility Definition and should be reported to Google but that is an other story. There is an easy workaround for the user which is to lock the app in the recent apps (the square bottom buttom, then upper right corner 3 dots, lock action).
I am now working on making the POC mergeable so that the next step will be to remove Firebase entirely.