Fixing notifications

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.

@pedro @andrey @andre @rachel

7 Likes

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.

1 Like

Yes, please, kill Firebase. It will make me so happy, as I’ll be able to get back to trying to publish Status on F-Droid.

3 Likes

As an Android user: :partying_face:

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.

cc @Simon @rramos @JoRain

I’m trying to get acquainted with everything. Is there anywhere where v2’s implementation is specced? I’d love to see what we’re missing out on :slight_smile:

@andre


1 Like

I think removing firebase as a dependency would be very beneficial :slight_smile:

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.

1 Like

Perfect, thank you! And I really appreciate the patience as I’m catching up with everything that’s going on.

1 Like

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.

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.

2 Likes

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

2 Likes

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:

  1. Can we conditionally (compiler flags) remove Firebase for e.g. F-Droid only?
  2. 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)
  1. 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
  2. Are any hybrid approaches possible, where Android PNs are kickass but iOS don’t degrade in capability?
  3. 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.
  4. Have we asked iOS users what they think?
  5. 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)?
  6. 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:

iOS

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

Exploration

I evaluated 3 libs:

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.

3 Likes