In Instanbul we talked a bit about notifications. The current implementation is still the original MVP and v2 never really came to life. So we are left with a very naive implementation that has been patched over time to limit the amount of metadata leaked.
We don’t like it for the following reasons:
it is still depending on one of the biggest third party lib in the codebase: Firebase. Yes, our push notifications are relying on a Google service, to be sent from one device to another through their server, using a token that is exchanged by contacts when they add each other.
the previous point is a blocker for the FDroid store
you might have expectations about when you are suppose to receive a notifications, but currently since you need to exchange tokens, notifications only work between contacts that added each other and who both enabled notifications in the device they are using. (I am not sure how it works with multidevice when one doesn’t have notifications enabled)
So as a result, notifications may sometime feel broken, when they are there and the app is locked they can’t tell more than just “You got a message”, They don’t work for mentions, or any kind of event you might be interested in
Improving them step by step
Remove current implementation and Firebase
We can now publish on FDroid, no notifications, no bugs
Ignore iOS
They don’t let you run background tasks except basic http, we forget about it
Kickass notifications on Android
We let the app run as a service, we can already start and stop the node while staying logged in. We keep the app in the badckground as a service and periodically fetch messages (based on user settings for frequency and network type).
We can now have more data in the notifications (they are local, user can choose how much data he wants to show in them though, like some other apps it can show nothing when phone is locked).
We can have notifications on mentions, messages from non contacts, follow keywords, dapp can send notifications too via status api.
iOS users have AR poo emojis, they can’t have everything.
Cool beans. Just to chime in on improving the UX of notifications, I made two designs for things which aren’t quite in place yet but likely should. One is for adding a Notification Center in the app that groups all notifications into a chronological timeline. And another is simply in-app notifications, so getting notified if you’re using the app and someone mentions you in a chat or a transaction gets confirmed.
To make sure it’s on the radar. How would DApp notifications be handled, if at all? I ask as Teller is sorely missing a way to notify users of trades being opened.
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.
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.
Right now, the only way to send messages from the Dapp is to use Murmur, which was developed by @rramos and @iurimatias, but having an extension or an API to do it would be even easier
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 Push notifications proposal - Google Documenten 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
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.
Android
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 服务概览 | Android 开发者 | Android Developers 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
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.
Thanks for your explanations on the dev call @yenda! Can you please ping @maciej and/or me when you get around to working on the service? As I understand:
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.
